From wwwrun@core3.amsl.com Thu Dec 10 12:56:56 2009 Return-Path: X-Original-To: nea@ietf.org Delivered-To: nea@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8A8BB3A6ADD; Thu, 10 Dec 2009 12:56:56 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091210205656.8A8BB3A6ADD@core3.amsl.com> Date: Thu, 10 Dec 2009 12:56:56 -0800 (PST) Cc: Internet Architecture Board , nea mailing list , nea chair , RFC Editor Subject: [Nea] Protocol Action: 'PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC' to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 20:56:56 -0000 The IESG has approved the following document: - 'PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC ' as a Proposed Standard This document is the product of the Network Endpoint Assessment Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-06.txt Technical Summary This document defines the PB-TNC protocol. PB-TNC is a Posture Broker protocol that aggregates posture attributes between one or more Posture Collectors on a NEA client and one or more Posture Validators on a NEA server. PB-TNC is equivalent to the Trusted Computing Group's IF-TNCCS 2.0 protocol. It addresses the PB protocol requirements defined in the NEA requirements specification. Working Group Summary The WG solicited proposals for the PB protocol based on the NEA reference model and requirements specified in RFC 5209. The TCG submitted a specification to the NEA WG in response to the call for proposals. There was broad support in the WG to adopt the submission as a WG document. Subsequent WG updates to the document have not been contentious. The protocol document specifies a base protocol and is extensible. The WG has discussed the potential for certain optimizations and extensions to the above specifications (e.g. assertion attributes). The proposed extensions did not share the same level of consensus as the base document and also represented significant additional work. The WG decided to defer potential extensions to supplemental documents in the interests of making progress on the base documents. Document Quality Several vendors have indicated their intention in public or private to implement the specification. Personnel Susan Thomson is the document shepherd. Tim Polk is the responsible Area Director. RFC Editor Note Section A.3.1.11., second para. Old Text PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) R bit=1 (Retry acknowledge) Batch Type=RESULT Batch Length } New Text PB Envelope { HDR { D bit=1 (Posture Broker Server is originator) Batch Type=RESULT Batch Length } From sethomso@cisco.com Fri Dec 11 14:43:47 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBC63A67F6 for ; Fri, 11 Dec 2009 14:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEqbSZSFn11O for ; Fri, 11 Dec 2009 14:43:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D427E3A67FB for ; Fri, 11 Dec 2009 14:43:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMRZIkutJV2Y/2dsb2JhbAC+bJcJhCsEgWM X-IronPort-AV: E=Sophos;i="4.47,384,1257120000"; d="scan'208";a="73712306" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 11 Dec 2009 22:43:30 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id nBBMhUqv019725 for ; Fri, 11 Dec 2009 22:43:30 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 16:43:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ALkK AfOk CreJ DHj3 DL6R ENPz Eh4H Eo2+ GPuP I3aG I40u JY80 KI48 KSfQ KsDq LYNz; 1; bgBlAGEAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {1042D6D6-021D-49F0-B773-849000450E14}; cwBlAHQAaABvAG0AcwBvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 11 Dec 2009 22:43:26 GMT; RAByAGEAZgB0ACAASQBFAFQARgA3ADYAIABOAEUAQQAgAG0AZQBlAHQAaQBuAGcAIABtAGkAbgB1AHQAZQBzAA== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {1042D6D6-021D-49F0-B773-849000450E14} Content-class: urn:content-classes:message Date: Fri, 11 Dec 2009 16:43:26 -0600 Message-ID: <043901FAFD488D44ACC9CCED00470BDC524FE6@XMB-RCD-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF76 NEA meeting minutes Thread-Index: Acp6s1pntz56daywSOGpESXhMA/A5A== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 11 Dec 2009 22:43:29.0968 (UTC) FILETIME=[5C4BB300:01CA7AB3] Subject: [Nea] Draft IETF76 NEA meeting minutes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 22:43:48 -0000 The NEA WG meeting minutes from IETF have been posted and are included below. Please send any corrections to me by Wed, Dec 16. Thanks Susan --------------------------------------------------- These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments=20 and discussion. Agenda =3D=3D=3D=3D=3D=3D Date: Monday, Nov 9, 2009 Time: 1740-1940=20 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=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan Thomson reviewed WG status.=20 Since IETF75, both PA-TNC and PB-TNC I-Ds were updated to address IESG=20 and other Last Call comments. The IESG has approved PA-TNC as a=20 Proposed Standard. The IESG is also ready to approve PB-TNC. However, a=20 few significant changes were made to the PB-TNC protocol. These changes=20 are currently in review in the WG with a call for comments by Nov 16.=20 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=20 PT protocols. A call for individual submissions has been made that ends=20 Jan 4, 2010. Review of Process for Working on Posture Transport Protocols: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan also reviewed the process for working on PT protocols. It is the=20 same process as followed for the PA and PB protocols.=20 Individual submissions will be reviewed in the WG after the Jan 4=20 submission deadline. The WG will then determine the contents of a -00=20 version of a WG document. Normal IETF process will follow from there.=20 Changes to -05 version of PA-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D After recapping the NEA reference model for the benefit of those new to=20 the WG, Steve Hanna proceeded to summarize the two sets of changes to=20 the PA-TNC and PB-TNC I-Ds made between IETF 75 and IETF 76.=20 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=20 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Removed section on TCG and replaced with acknowledgement=20 2. Tightened up error handling 3. Added a new CLOSE batch type 4. Added PT additional requirements=20 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=20 considered the most significant changes to the PB-TNC draft. Steve=20 elaborated on these two changes and re-iterated that the last call to=20 confirm consensus on these changes is Nov 16.=20 New CLOSE batch type: Steve explained that prior to this change, the way to indicate a fatal=20 error was to include a TLV in a (inappropriate) batch type, i.e. one=20 that would be sent under a non-error condition. There was also no way=20 to close a connection gracefully. Thus, an explicit CLOSE batch type was added to indicate fatal errors=20 and a non-error close. New PT Requirements: In response to comments from one of the Transport ADs, a new section=20 was added to PB-TNC to include additional PT requirements,=20 supplementing those in RFC 5209.=20 Additional requirements include that the protocol must be connection- oriented, be able to carry binary data, and provide mechanisms for flow=20 and congestion control. Also, the PT protocol specifications must=20 describe the extent to which these requirements are met. Changes to -06 version of PB-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=20 reasonable. There was no dissent. Conceptual Overview of PT Proposals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=20 submissions based on the above two transports. Specifications of these=20 protocols are available on the TCG web site.=20 PT-EAP: Steve explained that the use case for PT-EAP was to allow posture to=20 be considered in a network access control decision e.g. 802.1x and=20 IKEv2, while supporting isolation of endpoints for remediation, and=20 quarantining or blocking of non-compliant endpoints. The proposed protocol is designed to run as an inner EAP method which=20 can be chained with authentication and other inner methods within a=20 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=20 exchange to the outer tunnel, assuming the tunneled method supports=20 this.=20 One limitation of EAP is that it cannot support posture policies that=20 require the transfer of large amounts of data, e.g. examining all=20 hotfixes on a machine. This is because only one packet can be in flight=20 at a time. Other characteristics include that it is half-duplex,=20 supports simple congestion control, and is extensible. Steve said there are some open-source and commercial implementations of=20 the TCG protocol. Yaron Schaffer asked whether the rule of one packet in flight applied=20 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=20 packet is in flight at a time. Steve said that this is the reason why EAP should not be used for large=20 data transfers. Use PT-TLS instead. PT-TLS: Use cases for a TLS-based transport include networks where posture=20 policies require large amounts of data to be transferred, where=20 monitoring of posture compliance rather than enforcement is desired, or=20 for more detailed assessment or re-assessment after an endpoint has=20 been granted access to the network. Another use case may be an=20 application server that requires both authentication and posture=20 compliance for use of a service. The proposed protocol is designed to carry posture as application data.=20 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=20 authentication 3. Data Transport for posture assessment Steve said that the proposed protocol meets the PT requirements.=20 The #1 feature is that the protocol leverages the full capabilities of=20 TLS and does not reinvent the wheel. Features of a TLS-based protocol=20 include the fact that it has established security support (latest=20 discovered security flaw notwithstanding), is full-duplex and hence=20 allows server-triggered re-assessment, supports posture policy with=20 higher bandwidth requirements, is easy to implement using available TLS=20 libraries, and is extensible. Steve asked whether people have issues with having two proposed=20 standards-track protocols, rather than one. Tim said that, while he normally prefers one standards-track protocol, =20 in this particular environment, the use cases are different enough that=20 2 standards-track protocols are warranted. He would be prepared to=20 support both. Steve said that the tricky part is going to be to define which=20 protocols are mandatory to implement. One does not want to be in a=20 situation where a NEA client supports one standard, and a NEA server=20 the other. People need to think more about this, but one option is to=20 specify that both are mandatory to implement. Tim agreed that this requires careful thought. He suggested that the=20 option of having the NEA server support both (versus the client) may=20 indeed be the way to go.=20 Proposed Milestone Update: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Susan proposed an update to the current milestones. Because of the=20 delay in updating the charter to start work on PT, the dates associated=20 with the milestones in the current charter need to be extended by=20 roughly the timeframe of one IETF.=20 The intent is still to hold a virtual interim meeting in January to=20 expedite progress.=20 There was some discussion about the rules for conducting such a=20 meeting.=20 Tim said that his recollection was that a 30-day notice is required,=20 and that AD approval is needed in writing before sending an=20 announcement. There is an IESG statement on the topic that should be=20 read prior to arranging the meeting. A virtual interim meeting cannot=20 be held instead of a regular IETF face-to-face meeting; it is intended=20 to be in addition to existing meetings. [Editorial Note: On reviewing the IESG statement after the meeting, the=20 rules Tim mentioned above are for face-to-face interim meetings. For=20 interim meetings that are conducted via conference call, the rules are=20 relaxed somewhat, e.g. a 2-week versus 30-day notice period is=20 required.] The goal of the virtual meeting is to get consensus on the content of=20 the -00 WG drafts.=20 Steve pointed out that, as with any meeting, consensus will be=20 confirmed on the mailing list. Meeting adjourned.