Subject: [Nea] Draft IETF76 NEA meeting minutes

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Fri, 11 Dec 2009 16:43:26 -0600

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 
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: [email-masked]

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. one 
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 extent to which these requirements are met.

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. 

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.