Subject: [Nea] Draft minutes from IETF82

From: Susan Thomson <[email-masked]>
Date: Wed, 23 Nov 2011 20:22:05 -0500

Draft minutes below.

Please send corrections to me by Friday, Dec 2.

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.

Notes taken by Chris Inacio.

Agenda
======

Date: Thursday, Nov 17, 2011
Time: 0900-1130 
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: [email-masked]

0900 Administrivia
         Jabber & Minute scribes
         Agenda bashing
0905 WG Status
0910 NEA Reference Model
0915 Discuss and Resolve Open WGLC PT-TLS Comments
     draft-ietf-nea-pt-tls-01.txt
1000 Discuss and Resolve PT_EAP Issues
     draft-ietf-nea-pt-eap-00.txt
1100 Discuss next steps for NEA Asokan I-D
1115 Discuss Next Steps
1130 Adjourn

WG Status
=========
Susan Thomson reviewed WG status. Since the last IETF, PT-TLS I-D
has gone through WGLC. Several issues have been raised which will be
discussed in the meeting today. PT-EAP was published as a WG
document. Some comments have been received, but more are needed.

Discuss and Resolve WGLC PT-TLS Comments
========================================
Joe Salowey went through the list of issues that had been brought up
on the mailing list in response to WGLC.

Issues include:
1)TLS Keepalive
2)Version Negotiation
3)SASL Negotiation
4)PT Client as TLS Server
5)Channel Bindings

1) TLS Keepalive
To address the issue of how to keep the TLS session up, the proposal
is to use the TLS heartbeat mechanism described in draft-ietf-tls-
dtls-heartbeat. This draft is going through the IESG now, and should
be an RFC prior to the PT-TLS being published. The keepalive
mechanism would be optional to implement.

Stephen Farrell raised the question of whether it should be optional to
implement for both sides.

Steve Hanna said it could be mandatory to implement at the NEA server.

Joe asked for clarification of the use case.

Steve said that the use case would be that the TLS session needs to be
kept up to allow the NEA server to revalidate the client after some
period, which may leave a long time during which the TLS session is
not carrying traffic.

Nancy Cam-Winget asked for clarification on the need to implement the
TLS server on the NEA client.

Steve says that he is pretty sure that the draft does not require that
NEA clients need to implement the TLS Server.

Nancy says that this should be made clear in the draft.

Joe summarized by saying that the draft currently allows the NEA
server to be a TLS server or a TLS Client. If we made keepalives
mandatory to implement on the NEA server, this would enable the NEA
server to revalidate the client without having to start a new TLS
session (assuming the client supported it).

Joe continued that the keepalive capability is negotiated at the TLS
layer, so if the client did not support this, there would be a
degradation of service, not a hard failure.

Joe said that the editors would get together to think through the
ramifications of making this optional versus mandatory and make a
proposal to the list.

2) Version Negotiation
Regarding version negotiation, the draft says the following:
³Subsequent assessments on the same session MUST use the negotiated
version number and therefore SHOULD NOT send additional version
negotiation messages.²

The proposal is to change the SHOULD NOT to a MUST NOT.

Steve said that there is no point in allowing further version
negotiation given that the protocol forbids a different version to be
used during a session.

Joe says we would need to check that the draft handles the error case.

Alexey asked whether this discussion was referring to TLS version
negotiation.

Joe clarified it was PT-TLS.

There were no objections to making this change.

3)SASL Initiation
Currently, the draft allows for both the SASL client and server to
initiate the SASL exchange. This leads to some additional complexity
in the protocol, and the draft is not clear on the behavior in all
cases.

One proposal would be to have the TLS server always initiate the SASL
exchange since it has the policy determining whether the client needs
to be authenticated. The client would not have a way to initiate the
exchange.

Alexey asked a clarifying question about whether the server initiates
the exchange by sending a list of SASL mechanisms (answer is yes), in
which case he thought this proposal made sense.

Joe said the only need he can think of for the client to initiate the
SASL exchange is in the case where the client did not completely trust
 the server authentication done at the TLS layer, e.g. the trust root
was questionable, and wanted to fall back to inner authentication such
as a SASL GSS-API mechanism which allows for mutual authentication and
channel binding to be verified.

Joe thinks this is an edge case, and that we probably do not need to
support this.

Joe asked whether there were any objections to just supporting a
server-initiated SASL exchange.

There were no objections to this at the meeting, and further
resolution would be taken to the list.

Alexey asked whether, if authentication using one mechanism failed,
the client can try another one that has been advertized.

Joe says he is not sure how the draft deals with this at the moment,
but in the case where the server-initiated exchange only is supported,
the server could resend the mechanisms again.

Alexey said that he did not think it was necessary for the server to
send the mechanisms again, as the client already has the list and can
pick another one. But either way, the draft needs to explain how this
is supported.

Alexey says that supporting this functionality is common SASL usage.
Other protocols allow it.

Steve says that the draft does permit this now, where the PT-TLS
responder can send another SASL Mechanisms TLV if additional
authentication is needed. It does not explicitly call out the error
case, but does not preclude it.

4)PT-Client as TLS Server
The current draft allows the NEA Client to be a TLS Server so that the
NEA Server can initiate posture validation with the client. The
question is how to support server authentication in this case.

The proposal is to require mutual authentication at the TLS layer, and
not use SASL in this case, thus simplifying the protocol.

Steve says that while he is in favor of this approach, he does not
think we should prohibit SASL authentication.

Joe says that currently the SASL authentication is tied to the role
the NEA client and server are playing in the PT-TLS exchange. It seems
unlikely that the client would use SASL to authenticate the server in
this case, but its possible the server might want to do additional
authentication of the NEA client.

Hao Zhou says he believes the current draft says that the SASL request
can be sent only by the PT-TLS responder. If we want to allow this case,
then we would need to make a change.

Joe agreed, and said that there are probably other areas that need to be
clarified.

Steve said that assuming we decide to support this, we can rewrite the
text in terms of PT-TLS client and server (versus PT-TLS initiator and
responder) to make the expected behavior clearer.

To be continued on the list.

5)Channel Binding
It is desirable to be able to bind authentication to TLS channel, when
possible. For example, SASL GS2 mechanism provides for this.

The proposal is to describe this in the document. What Joe is not sure
about is whether there are other mechanisms that support this capability.

Alexey indicated that SCRAM does.

Joe asked whether they use the same data structure used in GSS-API for
tls-unique.

Alexey thinks so. He supports adding tls-unique channel bindings to the
draft. 

Steve says there are a couple of sentences on channel binding in Section
3.8.1 of the current draft, but more text needs to be added.

Susan asked whether there were other issues that the WG wanted to bring up.

Alexey brought up the following additional issues:

TLS Version: TLS1.1 is currently mandated. Concern that TLS 1.1 not
widely deployed, and suggested that TLS 1.2 should be mandated instead.
TLS 1.1. and 1.2 is available in libraries such as Opera, MS, OpenSSL
(trunk version). The proposal is to mandate TLS 1.2.

X.509 Certs: The draft does not specify what is expected in certificates,
such as make use of RFC6125. RFC5280 is not sufficient as it has too many
options. This works for the situation where client initiates TLS session,
but there is an issue in the reverse direction, where the server may not
know the client¹s name. Stephen Farrell agreed that the reverse direction
 is tricky, and asked whether there are privacy concerns that need to be
addressed as well. Joe indicated that we should note this as an issue in
Privacy Considerations.

PT-EAP:
Nancy went through the comments received on PT-EAP I-D. Looking for more
comments from the WG.

The draft currently uses several acronyms to refer to the EAP method, the
outer tunnel, or some combination. The proposal is to focus the document
on the EAP method which carries the NEA data only, and refer to it as PT-
EAP.  

Steve agreed saying we have enough acronyms already.

The above requires changes throughout the document. Specifically, Nancy
has proposed changes to simplify the abstract and introduction given the
above. She has also incorporated a comment from Steve Hanna that allows
the EAP method to run in an EAP tunnel method ³or equivalent protection²

Stephen Farrell raised the issue of what ³equivalent protection² really
means.

Steve said that the tunnel properties are defined in RFC5209 and in
security considerations.

Stephen responded that this leaves implementers hanging, but this is
acceptable as long as it is clear that a TLS tunnel method must be
implemented.

Hao said there are inconsistencies in the proposed text around requiring
an outer TLS tunnel method, or  ³equivalent protection².

Joe raised the question of whether this text is implying non-TLS-based
EAP tunnel methods.

Steve clarified that he wants to make sure that we support the proxy case
from one RADIUS server to another.

Joe says he still has a lot of problems with that use case and believes
there are security issues that need to be addressed in the document.

Steve said that there is an agreement to use EAP tunnel method, but there
is still disagreement on the proxy case. This needs to be addressed
directly on the mailing list, and if the consensus is that it is unsafe
to do so, the spec should prohibit it, and if it is safe to do so under
certain conditions, the spec must state what those conditions are.

Nancy then proposed to remove references to the TNC document within the
main text, and add text to the acknowledgements section.

Steve disagreed saying he thought it was important to let readers know
that the IETF spec and the TNC specs are equivalent. The TNC specs will
be updated to be the same as the IETF document.

Stephen Farrell says that this should be taken offline to come up with
text that makes everyone happy.

Nancy also proposed that a new EAP type should be assigned to PT-EAP.

Stephen F. asked about the process for allocating the new EAP type.

Joe suggested that at the time of WGLC, EMU WG be notified.

Stephen F. suggested removing the Appendix, which describes how the
protocol meets the requirements. It is no longer needed.

Hao asked why a version registry is needed in IANA considerations. If
changes are made, a new RFC will be issued.

Susan proposed not including support in PT-EAP for fragmentation, at
least where EAP tunnel method transports are mandated. EAP tunnel methods
will support sending packets of up to approx 64K as is, and if more
posture information needs to be transferred, then there is an alternate
mechanism to use which is PT-TLS.

Steve says he is fine with this as it encourages people to do the right
thing, and simplifies interoperability and testing.

NEA Asokan Analysis I-D
=======================
This I-D is referenced by both PT-TLS and PT-EAP I-Ds as informational.

The question is whether the WG wants to make this a WG document with the
intent to publish as an Informational RFC. A consensus check was taken
and no objections raised.

Stephen Farrell asked whether this would be useful to a more general
audience, otherwise the text could be included in one draft and the other
draft could reference it.

Steve said that the draft is currently focused specifically on the Asokan
attack in the NEA context, but it may be useful to raise awareness of the
Asokan attack in general.

Stephen F. suggested the draft be generalized so that it is not only
specific to NEA, assuming this was not too much additional work.

Joe said that it would be worthwhile investigating to see what it would
take as he thinks the document would be useful to a wider audience.

Next Steps:
Susan summarized the next steps.

The PT-TLS spec will be revised after all the issues have been addressed
and another WGLC done.

More comments are needed on PT-EAP. Hao and Kathleen volunteered to review
the document.

Joe and Steve will scope the amount of work needed to generalize the NEA
Asokan I-D.

Milestones
==========
Susan went through a new set of proposed milestones, as listed on the
slides. 

Stephen said that it looks like the NEA WG could be completed prior to
the IETF in Paris, and that we should not assume that we need a meeting
in Paris. It seems that with more mailing list participation, this is
doable. The forcing function is that if there is insufficient mailing
list discussion, then there may not be a meeting as agenda slots are
tight.

Meeting adjourned.