Subject: [Nea] Pros and cons of EAP and TLVs for L2 PT

From: Stephen Hanna <[email-masked]>
Date: Thu, 9 Jun 2011 13:03:52 -0400

As I mentioned in my recent email to the NEA list, the
PT draft editors have been working (as requested at the
last NEA WG meeting) on a list of pros and cons for
different approaches to the L2 PT protocol. This group
has now agreed on a set of pros and cons:

EAP for PT
Pro: Can export keys (but no clear value at this time)
Pro: Multiple Interoperable Independent Implementations
Con: More likely to accidentally be used outside EAP tunnel

TLVs for PT
Pro: Can run in parallel with authentication

Of course, these are just bullet points. They're quite
short and don't capture all the nuances of the issues.
Let's start up an email discussion on the NEA list where
we can elaborate on these points and discuss them. In the
end, I hope that we can reach rough consensus on what is
the best approach.

So let the discussion begin!

Thanks,

Steve

---

From: Joe Salowey <[email-masked]>
Date: Sun, 12 Jun 2011 21:24:32 -0700

I have some concerns over using an EAP method to carry posture.  EAP was designed for peer and server authentication.    Implementations and deployments expect EAP methods to authenticate a peer and server name which are often used for access control and/or accounting purposes.  Posture assessment does not necessary perform any authentication, so a stand-alone posture based EAP may not be usable in many environments.   If posture assessment is tightly coupled with some authentication method then it limits the capability to plug in different EAP authentication methods in a deployment.  Because of this disconnect between posture assessment and authentication, assessment should not be a stand alone EAP method, but rather a set of TLVs defined to be carried within an EAP tunnel method.

In addition, I am also concerned about the issues raised in the Prague meeting over running posture unauthenticated outside a protect tunnel.   This is not a generally safe practice.  There is a risk that a stand alone posture assessment EAP method will run unprotected across some portions of the network as is common practice today.  Using TLVs within a tunnel method would prevent the exposure of the posture assessment through the normal operation of EAP.  

Cheers,

Joe
On Jun 9, 2011, at 10:03 AM, Stephen Hanna wrote:

> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Jun 2011 16:24:57 -0400

Certainly, it's not safe to run PT-EAP (or any of the other PTs
proposed so far) outside an EAP tunnel method. Nesting in an
EAP tunnel method is clearly required in all the PT proposals.
I expect that the final L2 PT RFC will clearly state that it
MUST only be run inside an EAP tunnel method. One could create
an L2 PT that would be safe to run outside an EAP tunnel method
by adding authentication but there's no point in doing so since
we already have EAP tunnel methods and usually it's desirable
to combine user or endpoint authentication with posture assessment.

So I think we have established that the requirement to run the
L2 PT in an EAP tunnel method does not differ from one proposed
L2 PT approach to another.

Your contention that implementing L2 PT as an EAP method will
cause difficulties for EAP implementations and deployments is
not supported by the evidence. As documented in the slides for
the NEA WG meeting at IETF 80, there are at least nine separate
implementations of PT-EAP in use today. I have spoken to almost
all of the implementers and several deployers, asking for
feedback on the PT-EAP specification. I have not heard any
complaints that the use of an EAP method as a posture transport
caused any difficulties. In fact, I have been told that it made
the implementation easier since they didn't have to modify their
user interfaces. They already have a way for administrators and
users to select which inner EAP methods should be used in an
EAP tunnel method. This same technique was used to enable PT-EAP.

In order to further this discussion, I'm going to write a
separate email to elaborate on the pros and cons listed in
the original email on this thread.

Thanks,

Steve

> -----Original Message-----
> From: Joe Salowey [mailto:[email-masked]]
> Sent: Monday, June 13, 2011 12:25 AM
> To: Stephen Hanna
> Cc: [email-masked]
> Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT
> 
> I have some concerns over using an EAP method to carry posture.  EAP
> was designed for peer and server authentication.    Implementations and
> deployments expect EAP methods to authenticate a peer and server name
> which are often used for access control and/or accounting purposes.
> Posture assessment does not necessary perform any authentication, so a
> stand-alone posture based EAP may not be usable in many environments.
> If posture assessment is tightly coupled with some authentication
> method then it limits the capability to plug in different EAP
> authentication methods in a deployment.  Because of this disconnect
> between posture assessment and authentication, assessment should not be
> a stand alone EAP method, but rather a set of TLVs defined to be
> carried within an EAP tunnel method.
> 
> In addition, I am also concerned about the issues raised in the Prague
> meeting over running posture unauthenticated outside a protect tunnel.
> This is not a generally safe practice.  There is a risk that a stand
> alone posture assessment EAP method will run unprotected across some
> portions of the network as is common practice today.  Using TLVs within
> a tunnel method would prevent the exposure of the posture assessment
> through the normal operation of EAP.
> 
> Cheers,
> 
> Joe

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 24 Jun 2011 17:46:41 -0400

In this message, I'm going to expand on the pros and cons
that were originally listed for the EAP and TLV approaches.
These are my personal views, of course. Chair hat off!

> Pro: Can export keys (but no clear value at this time)

As described in RFC 5247, many EAP methods export keys
(MSK, EMSK, IV) for use by lower-layer protocols such as
IEEE 802.11 and IKEv2. These keys can also be used to
bind inner EAP methods to outer EAP tunnel methods,
preventing an Asokan attack. Since L2 PT protocols are
not supposed to be used outside a tunnel method and
another technique for addressing Asokan attacks is
already in all L2 PT protocols (TLS-Unique), there
is no clear value to exporting keys from an L2 PT.
Still, it makes me nervous to give up the ability
to use this feature in the future if a new attack
is discovered that can be addressed in this manner.

> Pro: Multiple Interoperable Independent Implementations

Do we still believe in running code? Certainly, this
should not be the sole determining factor in deciding
which approach to take but it seems that it should be
a factor. PT-EAP has 9 implementations. EAP-TLV has 1.

I would like to mention that one of the reasons why there
are so many implementations of PT-EAP is that PT-EAP is
a TCG standard: IF-T Protocol Bindings for Tunneled EAP
Methods (also known as EAP-TNC). RFC 5209 (our requirements
document) includes this requirement:

   C-5  The selection process for NEA protocols MUST evaluate and prefer
        the reuse of existing open standards that meet the requirements
        before defining new ones.  The goal of NEA is not to create
        additional alternative protocols where acceptable solutions
        already exist.

The proponents of EAP-TLV have argued that TCG standards
are not really open standards. Of course, there is no one
definition of the phrase "open standards" but TCG standards
fall into a similar category as SAML and XACML: developed by
an industry consortium and made available to all for free.

Another benefit of choosing a TNC standard is that they
have received security reviews from several organizations.
One of these reviews turned up the Asokan attack on posture
checking, which was immediately addressed (as were other
secure issues raised).

> Con: More likely to accidentally be used outside EAP tunnel

While this is true in theory, I think we can avoid the problem
by stating in the specification that implementers MUST NOT
permit this method to be sent outside a tunnel EAP method.
It's possible that implementers will ignore our requirement
but I expect that TCG will offer certification for products
that implement the L2 PT (as it has done for other TNC standards)
so any violation of such a requirement would be caught during
the certification process and flagged as a violation.

> Pro: Can run in parallel with authentication

This is definitely a valid point in favor of the TLV approach.
Running posture checking in parallel with authentication could
reduce the number of round trips needed for EAP. On the other
hand, running posture checking and authentication in parallel
could increase the complexity of implementation. And it would
be REALLY complex to make support for parallel posture checking
optional so I think we'll need to either require NEA clients to
support parallel posture checking or prohibit this feature.

One thing to note is that parallel posture checking is sometimes
not desired. The set of posture checks needed may depend on the
user's identity or role. In that case, you would want to run the
authentication before the posture check. And some organizations
avoid prompting the user for authentication credentials until
after the endpoint has passed a posture check. In that case,
you want to run the posture check before the authentication.

So I don't see this as being much of a Pro.

**Summary**

In summary, I think that we could go either way: TLV or EAP
method. There are Pros and Cons on both sides but none of
them are really substantial.

Therefore, I think we should favor the proposal that is
based on open standards, as required by our requirements
document: PT-EAP. This protocol has been implemented widely
and has received many security reviews. In contrast, the
EAP-TLV proposal (as pointed out in my slides for IETF 80)
is clearly not even a complete proposal. It's missing key
features like versioning and support for PB messages other
than PB-PA and has race conditions. It's just a sketch,
not ready for prime time. Well, that's my view, anyway.

Thanks,

Steve

---

From: Carolin Latze <[email-masked]>
Date: Sat, 25 Jun 2011 21:24:47 +0200

In general I think it is a good idea to take the proposal that has 
already implementations (will be easier deployed on a large scale). 
Furthermore I don't think it is really a problem that PT-EAP should 
never run outside a tunnel. There are more EAP methods available that 
could run outside a tunnel but shouldn't (such as EAP-MD5, ...). However 
I see the point that PT-EAP is no authentication method. But as PT-EAP 
has some implementations and might become a de-facto standard anyways, 
it might still make sense to go for PT-EAP.

Regards
Carolin

---

From: Joe Salowey <[email-masked]>
Date: Tue, 28 Jun 2011 09:55:25 -0700

> L2 PT approach to another.

[Joe] My biggest concern is the execution of PT-EAP outside the protected tunnel.  If the method is "hidden" inside a tunnel method then the impact to the external system can be mitigated.  I still have concern that using EAP framing for posture is not appropriate and will lead to special case code inside the tunnel method specifically to handle the method.  

> EAP tunnel method. This same technique was used to enable PT-EAP.

[Joe] This worries me a bit and illustrates my concern.  Most of the user interfaces I have seen only allow the selection of a single inner method.  If only a single inner method is selected you are either not performing authentication or you are performing an authentication that is specific to your PT-EAP implementation.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 28 Jun 2011 10:18:25 -0700

> is discovered that can be addressed in this manner.

[Joe] At this point, as you state, I don't see significant value in exporting keys.  If the posture process does generate key material then this can be used in whatever way is appropriate.  Its not clear to me at this point if you would want to use these keys in the exact same way you would use keys exported from a mutual authentication.  

> checking, which was immediately addressed (as were other

[Joe]  My concern is the existing implementations are special casing the inner PT-EAP method.  Since the work is already done it may not be a huge issue, however I don't think moving to a TLV framing would be a huge burden and I think in the long term it will be a more flexible approach.  

> the certification process and flagged as a violation.

[Joe]  If we go down the EAP route then I think this requirement and testing would be good as it brings the two proposals closer in terms of security.  

> So I don't see this as being much of a Pro.

[Joe] I agree that this is not useful in all cases, but in cases where posture and authentication do not depend upon one another I do not see that there is much complexity here and it can reduce the number of round trips.   I guess I don't see having it be optional as a huge complexity as an endpoint could signal whether it allows posture at a particular point in the process or not.    

> not ready for prime time. Well, that's my view, anyway.

[Joe] I don't think the delta is that great either and moving to a different framing would not be too burdensome.  While there may be some gaps in the current TLV definition these can be improved if the group feels that decoupling posture and authentication provides more flexibility, efficiency and security.