[Nea] Draft minutes from IETF80

["Susan Thomson (sethomso)" <[e-mail]>]

Draft minutes from IETF 80 below.

Please send any corrections to me by Wed, May 4 at 5pm PT.

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: 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: [e-mail]

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 difference 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 issues 
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.