Subject: [Nea] Two More PT-TLS Issues

From: Stephen Hanna <[email-masked]>
Date: Tue, 15 Nov 2011 10:33:45 -0500

In preparing the slides for this week's NEA meeting,
the chairs and editors have uncovered two more PT-TLS
issues that should be resolved. I'm sorry that
these weren't raised during WGLC but it's good that
they have been smoked out by the process and it's
best to get them resolved ASAP so here they are.
Let's discuss these on email and also during the
NEA WG meeting. 

First, PT-TLS supports a mode where the NEA Client
is the TLS Server and the NEA Server is the TLS
Client. In this mode, PT-TLS requires that the NEA
Client use an X.509 certificate to authenticate
itself during the TNC handshake (TLS server auth).
No requirements are placed on how the NEA Server
authenticates itself in this mode, although such
authentication is clearly highly desirable. Since
the NEA Server generally has an X.509 certificate
for the more common situation where the NEA Client
is the TNC Client, the simplest way to resolve this
seems to be to require the NEA Server to use its
X.509 certificate to authenticate itself during
the TLS handshake, performing TLS mutual auth.
This avoids the need for the NEA Client to support
authenticating the NEA Server with SASL, simplifying
implementation and testing.

In the NEA meeting at IETF 81, Trevor Freeman asked
why PT-TLS doesn't include a way to bind the inner
SASL authentication to the TLS tunnel. Without that,
an attacker could forward a SASL authentication
through multiple PT-TLS tunnels. We agreed to figure
out how to do channel binding and put that in PT-TLS.
However, that isn't present in the current draft.
It should be added.

Thanks,

Steve