[Nea] Minutes from virtual interim meeting held Jan 28, 2010

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

Meeting minutes from the virtual interim meeting held on Jan 28, 2010,
have been posted to the NEA WG wiki 

http://trac.tools.ietf.org/wg/nea/trac/wiki/Jan2010Interim

and are included below.

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: Thursday, Jan 28, 2010
Time: 0800-1000 PST / 1600-1800 GMT 
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: [e-mail]

0800 Administrivia
         Blue Sheets
         Jabber & Minute scribes
         Agenda bashing
0805 WG Status, Meeting Goal and Consensus Check Process
0810 Review PT submissions: TLS
   http://www.ietf.org/id/draft-sangster-nea-pt-tls-00.txt
0830 Review PT submissions: EAP  
   http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-00.txt 
   http://www.ietf.org/id/draft-cam-winget-eap-nea-tlv-00.txt 
   http://www.ietf.org/id/draft-cam-winget-eap-tlv-00.txt 
0930 Plan for developing WG I-Ds
0950 Next Steps
1000 Adjourn


Minute Scribes
==============
Brian Ford and Steve Hanna volunteered to take minutes. 

Agenda Bashing
==============
Susan Thomson reviewed the proposed agenda. No changes were needed.

WG Status
=========
Susan Thomson reviewed WG status. 

The PA-TNC and PB-TNC I-Ds are in the RFC Editor Queue. They are going 
through the final editing process and will hopefully be published soon.

Call for submissions for PT protocols ended Jan 4, 2010. One TLS
proposal 
and two EAP proposals were submitted.

Meeting Goal
============
The aim of this interim meeting is to review the PT proposals and
propose 
the path forward for developing WG drafts.

Consensus Check Questions:

Susan previewed the consensus check questions that would be asked at the

end of the call for the purpose of determining the path forward for WG 
drafts of the PT protocols.

For the TLS-based PT, there will be 2 questions:

1. Is there an interest in working on a TLS-based PT in general?
Possible 
answers are:
- Yes	
- No 
- Defer (decision pending some other action taking place)

2. Is there support for adopting the PT-TLS proposal, in particular, as
a 
-00 WG draft:
- Yes
- No 
- Defer (decision pending some other action taking place)


Similarly, for the EAP-based PT, there will be two questions:
3. Is there an interest in working on a EAP-based PT in general?
Possible 
answers are:
- Yes	
- No 
- Defer (decision pending some other action taking place)

4. What should we adopt as a -00 WG I-D?
- PT-EAP
- NEA-TLV
- Other / Defer

For answers of no/defer/other, we would like to understand why, so that 
we can figure out how to make progress.

Review of PT-TLS
=================
Paul Sangster reviewed the PT-TLS proposal and described how the
proposal 
meets the PT requirements laid out in RFC 5209 and the PB-TNC I-D.

PT-TLS is a TCG specification published last year. It has the same IPR 
grants as PA-TNC and PB-TNC.

PT-TLS supports posture assessment over TLS as an application. No
changes 
to TLS are required.

PT-TLS addresses the PT requirements for a L3 transport. Use cases 
include posture re-assessment, application services and non-802.1x-
enabled networks.

PT-TLS consists of 3 phases:
1. TLS Handshake (unchanged)
2. Pre-Negotiation 
   - version negotiation 
   - optional client authentication
3. Data Transport
   - NEA Assessment

PT-TLS supports client authentication during the TLS handshake. It also 
provides the ability for the NEA Server to request that the client 
authenticate after the handshake. PT-TLS defines a basic authentication 
mechanism similar to that for the web. The proposal provides a framework

for adding other authentication types later. 

The data transport phase carries PB-TNC messages and supports error 
handling.

The PT-TLS message format is similar to that of PA-TNC and PB-TNC 
containing a message type scoped by vendor-id. Like PA-TNC, a message 
identifier is used to aid in error processing.

Paul said that the pros of PT-TLS are that it runs over an established, 
secure, reliable, full duplex protocol, capable of carrying large
amounts 
of data. PT-TLS has been designed to be extensible.

One con of PT-TLS is that more work is needed on client authentication. 
Only a basic authentication mechanism is defined, but more
authentication 
types are likely needed.  Another con is that, since PT-TLS is not part 
of the TLS handshake, it is not independent of the application. On the 
other hand, it eases adoption.

Paul then opened up the floor to questions. 

Joe Salowey said that PT-TLS defines a new framework for client 
authentication and that he feels it would be better to use an existing 
one like SASL.

Paul agreed that this would be interesting to look at and that EAP is a 
possible candidate as well. He considers this area one of the areas that

needs more work.

Joe said that the draft does not provide sufficient detail on
certificate 
processing during the TLS handshake, not only on the client, but also on

the server. More specificity will help interoperability, e.g. proof of 
possession of private key, and making sure that the identity of the 
server the client is connecting to, is authorized to service the
request. 

Paul said that this sounds like best current practices that could be 
added even though the protocol being defined is running on top of TLS.

Joe added that the HTTP specification has included recommendations along

these lines and so this would be a good baseline to look at. 

Kaushik reiterated the point made by Joe re SASL. He also said some text

regarding state management and performance implications would be useful.

Paul said that there is a section on supporting reassessment which 
mentions state management, but more could be said regarding scaling 
implications. 

Nancy said that the document was inconsistent in its use of TLS
versions. 
Nancy recommended that there be a requirement for TLS 1.2.

Paul said that there was text in the document regarding use of TLS 1.1 
(must) and 1.2 (should). A mandatory requirement for TLS 1.2 could be 
considered.

Joe added there was mention of TLS 1.0 in the document which needed to
be 
cleaned up.

Review of PT-EAP
=================
Steve Hanna reviewed the PT-EAP proposal and described how the proposal 
meets the PT requirements laid out in RFC 5209 and the PB-TNC I-D.

The PT-EAP proposal is a TCG standard and was published around 5 years 
ago.

PT-EAP supports an NEA assessment over an EAP tunnel method. Supported 
tunnel methods include PEAP, EAP-FAST and TTLS. No changes are required 
to the EAP tunnel method.

The use case for PT-EAP is to provide the ability to perform posture 
assessment in networks deploying access control such as 802.1x and
IKEv2.

PT-EAP runs as an inner EAP method. PT-EAP has the following properties:
- can be chained with other EAP methods used for authentication
- supports key derivation allowing inner method to be bound to tunnel
- supports fragmentation

Due to EAP limitations, the protocol is lock-step, allowing only one 
packet in flight at a time. Large data transfers are therefore not 
recommended.

PT-EAP supports 3 phases:
1. Optional Diffie-Hellman pre-negotiation
   - derives key
2. PB-TNC exchange 
   - NEA Assessments
   - Hashed into eventual key
3. Optional key derivation and export

Steve stated that the pros of PT-EAP include the fact that it works with

any EAP tunnel method, and that there are no changes to the EAP state 
machine and supplicant implementations (assuming they support adding EAP

methods).  It provides for protection against lying endpoints when used 
with TPM. The protocol has undergone security reviews, and it has no 
dependencies on other working groups. 

The cons are that key derivation and export adds complexity to the 
protocol, but its use is optional. A client need not support it.

Steve then opened up the floor for questions.

Nancy questioned the assertion that there is no external dependency. She

said there is a dependency on a standard EAP tunnel method for 
interoperability.

Steve said there are a lot of EAP methods that are best run in tunnel 
methods. The IESG has not held up standardizing these methods. So he
does 
not believe there is a dependency on defining a standard EAP tunnel 
method.

Joe said that one difference between PT-EAP and other EAP methods is
that 
it requires that it be run in a tunnel method, whereas other EAP methods

do not require it. 

Steve said that it would be possible to add security measures to run 
without a tunnel method. 

Nancy says it is still not clear to her what the threat is that is being

countered with the key derivation and export, and why that same threat 
does not need to be addressed in the PT-TLS proposal.

Steve says that he thinks that the WG might decide that it needs to be 
addressed in a TLS-based protocol as well. The threat is a man-in-the-
middle attack against a EAP tunnel method, where an attacker injects an 
EAP exchange in the tunnel from another endpoint. This allows a 
compromised endpoint to claim to have the posture of a clean endpoint
and 
not be detected. By binding the inner EAP method to the tunnel, this 
ensures that the tunnel and the inner EAP method terminate on the same 
device.

Nancy asked how the Diffie-Hellman is being authenticated. 

Steve says it is through a PA-TNC message over PT-EAP. He said this is 
not specified in the draft, but is described in full in the TCG 
specification. He tried to summarize it in the draft, but it may have 
been too brief.


Paul says this is specified in Section 3.5.3 of the draft, but it may 
need to be clarified. 

Joe said that without this critical piece, it is incomplete.

Steve says it may be useful to write an Info RFC on the PA-TNC exchange 
to explain how this works. He does not believe it is normative.

Kaushik asked whether the channel binding work being discussed in EMU WG

would make the Diffie-Hellman redundant.

Steve did not think channel binding would ensure that the posture check 
terminated on the same device as the tunnel.

Kaushik said that there seemed to have been a change in the trust model 
and questioned why the threat was protected against in PT-EAP and not
PT-
TLS.

Steve said that the WG could look at different options that solve the 
problem for both posture transports.

Paul said it is plausible to carry the D-H pre-negotiation in PT-TLS.

Nancy said it would be good to get a good understanding of the trust 
relationships and the problem statement. 

Steve suggested that people read Section 4.2.5 and the TCG spec (which 
has pictures).

Review of NEA TLV
==================
Nancy Cam-Winget reviewed the NEA TLV proposal and described how the 
proposal meets the PT requirements laid out in RFC 5209 and the PB-TNC
I-
D.

This proposal defines a general EAP-TLV container, and the NEA-specific 
TLV that is carried inside the general container.

The general EAP-TLV container facilitates the exchange of arbitrary data

in tunnel methods that do not need to generate keys. The EMU WG has 
discussed various uses for such a container such as channel and crypto 
binding. NEA assessment is another usage.

The use cases for an EAP-based transport are similar to those described 
in PT-EAP above. Also, the same EAP protocol limitations apply.

The protocol flow consists of:
1. EAP tunnel method set up (no change)
2. Inner EAP method for optional user/machine authentication (no change)
3. NEA Assessment exchange using NEA-TLV

Nancy said that the pros of the protocol are that it is simple and 
extensible, and can be carried inside of existing EAP tunnel methods.
The 
NEA-TLV  format could be used in the TLS-based protocol as well.

The cons are that this approach assumes that key derivation is not 
required. It also depends on the EAP-TLV format being defined.

Nancy then opened up the floor to questions.

Steve asked how requirement C-5 which states that the selection process 
must prefer open standards is met. 

Nancy argued that the EAP-TLV container is open in the sense that it is 
already used in existing tunnel methods.

Steve disagreed but said that we should let the WG decide. 

Steve also asked about C-7 and support for large data transfers.

Nancy says fragmentation is assumed to be supported in the EAP tunnel 
method.

Steve agreed with this, but TLVs larger than 2**16-1 would not be 
supported.

Nancy says the current proposal could be extended to support 
fragmentation into EAP_TLVs, if needed.

Steve agreed that this could be done.

Paul asked for a clarification on whether EAP-TLV I-D would be specified

in EMU WG and NEA-TLV in the NEA WG.

Nancy said that this was correct.

Paul said that the implication of this was that progress in the NEA WG 
was tied to that of the EMU WG. It was unlikely that the NEA-TLV I-D 
could be published as an RFC prior to the EMU WG completing the EAP-TLV 
specification. 

Kaushik said the relationship exists already because of the need for a 
tunnel method to be standardized.

Paul argued that this was not the case for the PT-EAP proposal. Even if 
the IESG decided not to publish the RFC as Proposed Standard straight 
away, the NEA WG could complete the work independently of progress in
the 
EMU WG.

Steve asked whether EAP-TLV required changes to the EAP state machine.

Nancy said that it did not require changes to the state machine.

Steve asked how existing supplicants that provide support for adding new

EAP methods would support the NEA-TLV without requiring changes to 
implementations.

Hao Zhou said a mechanism that would be needed to support NEA-TLV is 
required anyway, e.g. for returning final results and to support crypto-
binding. Several implementations support this.

Steve said that supplicants supporting multiple inner EAP methods can 
support PT-EAP without change.

Joe countered that not all supplicant implementations support this. Some

support TLVs. 

Consensus Check
===============
Susan asked the WG for their feedback on the consensus check questions:

Regarding the TLS-based PT:
-----------------------------
1. Is there an interest in working on a TLS-based PT in general?

The response was unanimous in favor of working on a TLS-based PT.
Prior to the next consensus question being asked, Nancy expressed the 
concern that she could not support PT-TLS without a better understanding

of the trust model, especially with respect to the authentication.

Paul said that D-H pre-negotiation could be added to the specification 
without a problem. Adding SASL may be a bigger change. But it is doable.

Susan then asked the second consensus question.

2. Is there support for adopting the PT-TLS proposal as a -00 WG draft?

The response (hum) was in favor of the yes responses, over the defer 
responses, with no-one humming no, but there was no clear consensus.


Regarding EAP-based PT:
-----------------------
Susan asked consensus check questions on the EAP-based proposals.

3. Is there an interest in working on a EAP-based PT in general? 

The response was unanimous in favor of working on an EAP-based PT.


4. What should we adopt as a -00 WG I-D?
- PT-EAP
- NEA-TLV
- Other/Defer

Responses were roughly equal in favor of PT-EAP and NEA-TLV with one 
response indicating a preference to defer.

Next Steps:
===========
Given the lack of consensus on moving forward with any of the proposals 
as -00 WG drafts at this time, the working group identified topics that 
need to be discussed on the mailing list, prior to making a decision.

Susan suggested that getting agreement on the trust model would help
move 
things forward.

Paul suggested that the WG chairs discuss with the AD questions around 
the process for publishing the EAP-based PT as a Proposed Standard. 
First, can a EAP PT progress without there being a standard EAP tunnel 
method? Second, is it OK to stop work until EAP-TLV is standardized?

Brian Ford mentioned that the impact of the EAP proposals on supplicants

be a factor taken into consideration.

Steve said another topic for discussion would be a description of the 
MITM attack and the D-H PN counter-measure.

Joe agreed on the need for a discussion of the threat model, and the
need 
for a binding to the tunnel.

Steve would like to see a discussion of how the EAP protocols stack up 
against the requirements because there are specific cases where there
was 
no agreement.


Actions:
- Steve and Paul to send description of the MITM attack and the D-H PN 
countermeasure.
- Steve and Nancy to describe how proposals meet PT requirements on 
mailing list
- Impact on existing supplicants. (Juniper-Steve, Cisco-Nancy,
Microsoft-
Steve, Apple-Nancy/Steve, open source-Paul)
- Susan and Steve to consult with our AD on process for moving forward
on 
standardizing an EAP-based PT.