[Nea] NEA Minutes from IETF 83

[Stephen Hanna <[e-mail]>]

Here are the draft minutes from the NEA WG session
at IETF 83 last week. Please review and send any
comments or corrections within the next week.

Thanks to Kathleen Moriarty and Yoav Nir for
taking minutes during the session. Any errors
are surely mine.

Thanks,

Steve

------------

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

The meeting was chaired by Steve Hanna and Susan Thomson.
Notes were taken by Kathleen Moriarty and Yoav Nir.

Agenda
======

Date: Wednesday, March 28, 2012
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
     NEA Reference Model
1315 Discuss and Resolve WGLC PT-TLS Comments
  http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-02.txt
1350 Discuss and Resolve WGLC PT-EAP Issues
  http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-01.txt
1425 Discuss next steps for NEA Asokan I-D
  http://tools.ietf.org/id/draft-salowey-nea-asokan-01.txt
1450 Next Steps
1500 Adjourn

Administrivia
=============

Steve got Jabber and minute scribes and reviewed the Note Well.
The agenda was bashed with no changes needed. Steve mentioned
that our documents are almost complete. In fact, they should
be complete and off to the IESG before the next IETF meeting.
So this may well be the last NEA WG meeting!

WG Status
=========

Steve reviewed the NEA Reference Model and Use Cases, as described
in RFC 5209.

Since the last IETF, the PT-TLS I-D has been revised to a -02 version
and gone through a second WGLC. A few new issues have been raised.
Similarly, PT-EAP has been revised to a -01 and gone through a first
WGLC. A few new issues have been raised. The NEA Asokan Attack Analysis
has been brought up to date and a decision has been taken by the WG
to not generalize it beyond since that territory is already covered
well by the original Asokan paper.

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

Paul Sangster gave an update on PT-TLS, including a quick overview
of the protocol and a description of the changes made in the -02
version. The largest change was simplifying things so that the
NEA Server always starts the SASL authentication. This avoids a
possible race condition. Some clarifications were also made.

Stephen Farrell suggested that it might be useful to support DANE
as an option for TLS server authentication here in addition to X.509.
At least, we should consider whether we want to support DANE since
it is available. We agreed to take this offline and decide whether
it makes sense to do so.

Paul moved on to review the comments on PT-TLS received during the
second WGLC. He included proposed resolutions for the comments.
First, we should add a mention of PT-EAP in the introduction.
Second, rephrase the text in sections 3.5 describing the Message
Identifier field to clarify its purpose and add normative text in
section 3.9 saying that the Copy of Original Message field MUST
contain a copy (up to 1024 bytes) of the original PT-TLS message
that caused the error. Third, add text in the description of the
SASL Mechanisms message type to say when this message type can
be sent.

Susan asked if the NEA Server is always required to send a SASL
Mechanisms TLV in the PT-TLS Negotiation phase. If not, the NEA
Client may not know when that phase has ended. Paul said that
the NEA Server always ends the PT-TLS Negotiation phase by
sending a SASL Mechanisms TLV with no mechanisms in it. He will
improve the text to make this clear.

The plan is to make these changes and then send PT-TLS off to
the IESG. There were no objections in the room.

Discuss and Resolve WGLC PT-EAP Issues
======================================

Nancy Cam-Winget gave a quick overview of PT-EAP. She did not
review all the issues that were addressed by draft -01 but
she listed them in the slides for reference. Instead, she
focused on a few issues raised before draft -01 was published
that have not been resolved yet and also a few issues that have
been raised since the -01 draft was published.

First, should we move all normative text out of the Security
Considerations section into a separate section so it isn't
ignored? After a bit of discussion, a hum showed unanimous
agreement within the room that the normative language should
move out of the Security Considerations section into a
separate Security Requirements section. This will be
confirmed on the list.

Second, should we have one MTI EAP tunnel method in section
4.3 to ensure interoperability? Or at least mention that a
standard tunnel method is coming (TEAP)? Joe Salowey said
that the TEAP effort is a bit behind PT-EAP but accelerating.
He suggested that we include an informative reference to TEAP.
And if TEAP catches up with PT-EAP, we can make that normative.

Stephen asked why we don't make EAP-FAST or EAP-TTLS mandatory.
Nancy said they're Informational RFCs and there's a Standards
Track RFC coming soon. We're happy with TEAP but we don't want
to wait for it. Stephen suggested that we add a sentence
explaining why we're not including a MTI tunnel method.
And we can revise the document to add one later.

Nancy explained that the other comments received on -00 are
listed in the slides. They were all addressed in -01.

Nancy reviewed all the comments received since -01 was
published. Most of these were minor editorial issues.
Nobody had any objections to Nancy's proposed resolutions.
The only comment for which she requested feedback was
Carolin Latze's comment that the tls-unique channel
binding only works with TLS. We'll mention that.

Discuss next steps for NEA Asokan I-D
=====================================

Joe Salowey outlined the NEA Asokan attack and described
how this attack can be thwarted with an EMA such as a TPM
and the tls-unique channel binding. This is all covered
in draft-salowey-nea-asokan-01.txt. Putting all of this
in one document avoids the need to duplicate it in the
PT-EAP and PT-TLS drafts.

At the IETF 82, we agreed to have Joe and Steve research
whether this document should be made broader to cover
Asokan attacks outside of NEA. Their recommendation is
to not do so. The original Asokan paper already does a
good job of describing how the Asokan attack works in
authentication and how to address it there. And some new
attacks based on Asokan in the ABFAB domain have recently
been discovered and discussed in the EMU WG. Those should
be discussed separately since the impact and countermeasures
are different.

Since IETF 82, the NEA Asokan Attack Analysis draft has
been updated to reflect the latest changes and choices
in the NEA WG (selecting PT-EAP and using the tls-unique
channel binding). It's ready to be adopted as a WG draft
(as agreed at IETF 82) and then to enter WGLC.

Hao Zhou asked which requirements for the EAP tunnel
method are imposed by this draft. Joe answered that the
requirement is that the EAP tunnel method must export
the tls-unique value to PT-EAP. Hao says this should
be listed more clearly in the PT-EAP tunnel method
requirements. Not just that the tunnel method must
support tls-unique but also that the method must export
the tls-unique value to PT-EAP. Joe said that we should
also state this in the TEAP to say that implementations
should support exporting the tls-unique value.

Joe explained that the plan is to post this as a WG draft
then run a quick WGLC so that this can catch up with the
other drafts. Then we'll send this to the IESG.

Steve checked consensus on adopting this document as
a WG draft. The hum was unanimous in favor. A show of
hands indicated that eight people in the room have
read the document.

Next Steps for NEA WG
=====================

For PT-TLS, the PT-TLS I-D will be updated to reflect
WGLC comments. Then it will go to the IESG for Standards
Track.

For PT-EAP, the editors will update the I-D. Then it
will go to EMU WG for review. We'll handle any comments
received from them. If a second WGLC is needed, there
will be one. And then the document will go to IESG for
Standards Track.

For the NEA Asokan Attack Analysis, we'll publish an
updated version as a WG draft. Then it will go through a
WGLC. And finally it will be sent to IESG for Informational.

Steve reviewed a draft timeline based on these plans.
See the slides for details. We hope that by the end
of May, all of our drafts should be with the IESG.
The NEA WG will need to respond to IETF LC comments
and IESG comments but we shouldn't need to meet again
unless something surprising happens.

Meeting adjourned.