[Nea] Draft NEA WG minutes from IETF 81

[Stephen Hanna <[e-mail]>]

Included below is a first draft of the minutes for
the NEA WG meeting at IETF 81. Thanks to Mauricio
Sanchez and Kent Landfield for taking notes. I have
combined their notes and added a bit of material
from the audio recording of the meeting.

Please review these minutes and send any comments
or corrections to the [e-mail] email list by
end of day August 15.

Thanks,

Steve

-----------

Minutes of NEA WG Meeting at IETF 81

These notes do not attempt to duplicate the content of the slides.
Instead, they summarize the material presented, and focus on comments
and discussion.

Notes taken by Mauricio Sanchez and Kent Landfield

Agenda
======

Date: Wednesday, July 27, 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
         Jabber & Minute scribes
         Agenda bashing
1305 WG Status
1310 NEA Reference Model
1315 Discuss and Resolve Open PT-TLS Comments
     draft-ietf-nea-pt-tls-00.txt
1400 Discuss and Resolve EAP vs. TLVs for L2 PT
     draft-cam-winget-eap-tlv-03.txt
     draft-hanna-nea-pt-eap-01.txt
1500 Adjourn

WG Status
=========
Susan Thomson reviewed WG status. We now have a WG draft for
the TLS-based transport. Please review and comment. Plan to
do a WGLC on this soon. For the EAP-based transport, we have
two competing proposals with no agreement yet. Today, we'll
discuss the key differences between the proposals as agreed
by the proponents. Maybe that will help us get WG consensus.
If not, we have agreed that our AD will decide.

NEA Reference Model
====================
Steve Hanna reviewed the NEA reference model for the benefit
of those new to the WG.

Discuss and Resolve Open PT-TLS Comments
========================================

Paul Sangster described the latest PT-TLS specification,
draft-ietf-nea-pt-tls-00.txt. The main new change is the
addition of messages to carry SASL authentication.

Paul asked several questions:

1) The SASL TLVs are mandatory to implement and optional to
   use. Is that OK?

Nobody in the room objected.

2) The PLAIN and External SASL Mechanisms are mandatory to
implement. Is that OK? Do we need any other mechanisms?
We could include some as a SHOULD or a MAY.

Paul pointed out that other commonly used SASL mechanisms
include Kerberos or GS2, which supports certificate-based
client authentication.

Mike Boyle said that it would be extremely desirable to be able to do
both user and device authentication using certificates, at least for
certain circumstances. Paul suggested saying that if your
implementation is intended to be used in environments where it's
desirable to do both user and device authentication using
certificates, then you SHOULD support GS2.

Trevor Freeman pointed out that this is a tunneled authentication
protocol but there's no channel binding. Paul described how the draft
calls for TLS-Unique to be used to bind the TLS session to an External
Measurement Agent like a TPM. Trevor said that when you use the
Kerberos SASL mechanism, you must make the client prove possession of
the shared secret. Paul said this could be done by hashing TLS-Unique
with the Kerberos secret and having the TPM sign that hash.

Joe Salowey asked whether the kitten WG has defined a way to do
channel binding with SASL. Shawn Emery said they have with GS2. He's
not sure if it will work for all mechanisms.

Klaas Wierenga suggested supporting SCRAM since that supports channel
bindings. Joe said GS2 is probably more useful for our use
cases. Klaas said GS2 has lot of other benefits.

Paul asked whether we should make GS2 a SHOULD. Shawn said yes. Joe
said the important thing is to talk about channel bindings and how to
do them with SASL. We can make it a MAY, as long as we explain how to
do it.

Paul agreed that he'll make GS2 a MAY and talk to the kitten folks
about channel bindings so that we can explain how to do that properly.

Paul said the next step is to publish a -01 draft (preferably in
August) and then do a WGLC. We'll discuss any substantial comments
from WGLC at IETF 82.

Stephen Farrell asked about trust anchor storage. Will we have any
guidance on that? Paul said that we don't know. Stephen said that we
should so that people know not to just use the operating system's list
of trust anchors.

Discuss and Resolve EAP vs. TLVs for L2 PT
==========================================

Steve Hanna and Nancy Cam-Winget came to the front and gave a joint
presentation on the key differences between the two competing
proposals: PT-EAP and EAP-TLV. The presentation was only one slide but
after each line on the slide there was discussion of that line. Here
is a summary of the discussion. However, this cannot do justice to all
the details given in the full discussion. For that, listen to the
audio recording.

Encapsulation:

Steve favors using an EAP method to carry NEA messages. Nancy favors
using a general container approach that can ride across many
transports (including EAP). We are not really doing authentication,
architecturally.

Proxy: 

Steve favors usage of EAP because facilitates proxy behavior,
specifically the ability to proxy NEA exchanges beyond the end of the
EAP tunnel method. Nancy feels the EAP framework is too tied to the
authentication process/RADIUS too much. Should be about NEA
client/server framework, not a AAA framework. Also, security of
EAP-TNC not guaranteed.

Nancy: Could have strong language in draft requiring strong protection
for the NEA exchange.

Joe: Sees proxying as not a useful feature. Spent a lot of time over
10 years moving away from insecure EAP methods. EAP-TNC introduces
special cases to keep it secure.

Steve: Proxying is clearly valued by some people. Stefan Winter
recently emailed the NEA list, saying that proxying should have been
included in the original NEA requirements. Clearly, any such proxying
would need to be protected. Regardless of approach, our draft should
mandate that the NEA exchange be strongly protected at all times.

Joe: Feels that TLV approach allows security to be built into the
design easier.

Klaas: Thinks ability to proxy is very important. Can't assume trust
relationship between client and server. Example is eduroam.

Stefan Winter (via Jabber): Yes, proxying is a desirable property. But
it's important to be able to blend together the result of the
authentication with the NEA exchange.

Joe: Proxying can mean different things. Proxying entire conversation
can be done with either approach. Proxying components of the
conversation does lead to a different capability.

Implementations: 

Nancy: The EAP-TLV approach is based on several existing working
models. Microsoft SoH uses a TLV approach.

Steve Hanna: PT-EAP is equivalent to EAP-TNC, which is a TCG spec that
is 5 years old and has 9 independent implementations. There have been
many security reviews and several papers written on EAP-TNC also. If
we're talking about architecturally similar implementations (like SOH
is to EAP-TLV), there are several proprietary implementations that use
an EAP approach.

Stephen Farrell: Asks about deployments of TCG specification.  Steve
H: Millions of users, however unclear how many are leveraging a close
variant of EAP-TNC. Of course, the latest NEA transport drafts added
TLS-Unique for use with hardware-based health checks. But nobody does
that anyway, at least now.

Nancy: Reiterated whether group really wants to promote what is an
insecure EAP (EAP-PT).  Steve responds that authentication could be
added to our L2 PT if need be, but it was not a requirement since the
EAP tunnel method handles that. EAP-TLV also has no built-in security.

Architecture:

Nancy: EAP-TLV uses a TLV transport since transport is the goal, not
authentication. Using EAP for a non-authentication purpose causes
problems.

Steve H: As we saw in a discussion on the list recently, most EAP
implementations today (like Windows 7) have a pluggable architecture
for adding new EAP methods but not for adding new TLVs. Nancy retorts
that it's exactly that pluggable architecture that highlights the
opportunity to run PT-EAP unprotected. Nancy asks whether EAP tunnel
methods handle multiple inner methods or whether they handle it
consistently. Main point is that software upgrades will need to be
done with either method.

Joe S.: One additional concern between authentication
vs. non-authentication is that the EAP RFCs define quantities that an
EAP method should define, like peer ID and server ID. While you can
operate without those, on the server side the lack of that information
is problematic because it doesn't know what it should do if it needs
to make authorization decisions. We may be able to special case, but
all with additional complexity.

Authentication/NEA sequencing:  

Steve: EAP-TLV can run the NEA handshake in parallel with an EAP
authentication. PT-EAP can't. There are some good reasons to do
authentication in parallel with NEA handshake, but that can also
introduce some undesirable traits. Some orgs want authz first then
NEA, others reverse.

Nancy: Early on identified need to do both serial and parallel approaches.  

Steve: EAP-TLV draft not entirely clear how serial and parallel should
be done.

Nancy: This can be cleaned up in future drafts.

Key export:

Steve: We used key export early on, before we decided to move to
TLS-Unique. Very useful for binding the inner and outer EAP
methods. At this point, value of being able to do key export is not as
clear.

Nancy: Design goal for EAP-TLV is just for a transport and not
authentication. Moreover, key export capabilities in PT-EAP are
suspect in security.

Joe: Worried that design of key export in PT-EAP is fragile.

Steve: Actually, key export was dropped from most recent draft of
PT-EAP. Could be added back in but it's not in there now.

Standards:

Nancy: EAP-TLV is a new proposal.

Steve: One of the requirements in the NEA Reference Model is that we
have to prefer existing open standards. PT-EAP is definitely a
standard. Whether you consider it open or not depends on your
definition of open standards. It's available for free from the TCG web
site and has been for five years. The I-D has been contributed to the
IETF Trust so at this point it's up to IETF to decide what to do with
it.

Susan did a consensus check.

Prefer PT-EAP?  6 in favor
Prefer NEA-TLV approach?  6 in favor 
Neither? 0 prefer neither

Next Steps:

Stephen Farrell (AD) discussed next steps given result. Stephen will
be gathering opinions over the week online and offline. He will be
thinking about it over next several weeks and make decision by the end
of August. Then he'll post his decision to the NEA list.

Steve H. asked for consensus check on process of having AD choose
between PT-EAP and EAP-TLV. More than 12 people are OK with AD
choose. Nobody is against.

Nancy asked if we need to have a formal consensus check on process on
the email list since WG chairs and ADs can make process
decisions. Agreed that there's no need to have do a formal consensus
check on that. However, we will do a formal consensus check on PT-EAP
vs. EAP-TLV (2 weeks on the list) and we'll warn people that if that
consensus check fails to produce a consensus, our AD will decide.

Milestones
==========

Susan went through a new set of proposed milestones, as listed on the
slides. There were no questions or comments.

Meeting adjourned.