Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches

From: Lisa Lorenzin <[email-masked]>
Date: Tue, 12 Jul 2011 11:24:48 -0700

Greetings!

Based on the meeting minutes and previous discussion thread,
it looks to me like a) there are pros and cons to each
approach, and b) either approach would accomplish the
technical goals.

In the absence of a clear technical front-runner, layer 8
considerations take on greater significance.  Since PT-EAP
has many more technical implementations, and is based on
an open standard from TCG, it seems to better conform to
the IETF's emphasis on running code, and to better comply
with the RFC 5209 requirement to "prefer the reuse of
existing open standards that meet the requirements before
defining new ones."

Based on those considerations, PT-EAP seems like a better
choice.

                                                Regards,

                                                        Lisa

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Susan Thomson (sethomso)
> Sent: Thursday, June 30, 2011 18:31
> To: [email-masked]
> Subject: [Nea] CALL for COMMENTS on EAP PT approaches
>
> One of the outstanding items in the NEA WG is to come to consensus on
> whether to use EAP method or TLV for carrying NEA data in an EAP-based
> transport.
>
> Steve Hanna has initiated a thread on this topic on the
> mailing list to
> which some have responded (see pointer below to email thread and to
> meeting minutes for summary of discussion at IETF 80).
>
> We need more input from the WG to make a decision. Please review the
> pros and cons laid out in the thread and provide your input. Feedback
> may include any considerations that you think might be
> missing from the
> discussion, as well how you would weigh the characteristics of the two
> approaches.
>
> The deadline for making a decision is by the July IETF. If we do not,
> our AD has "offered" to make the decision for us! So please take the
> time to post your views. I think it would reflect poorly on
> the WG if we
> are unable to come to consensus ourselves.
>
> Thanks
> Susan
>
> Email Thread starts here:
> http://www.ietf.org/mail-archive/web/nea/current/msg01120.html
>
> Meeting minutes from IETF 80:
> http://tools.ietf.org/wg/nea/minutes?item=minutes80.html
>
>
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>

---

From: Paul Sangster <[email-masked]>
Date: Tue, 12 Jul 2011 13:28:47 -0700

Well said Lisa, I have to agree with your comments.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lisa Lorenzin
> Sent: Tuesday, July 12, 2011 11:25 AM
> To: [email-masked]
> Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches
> 
> Greetings!
>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 21 Jul 2011 14:49:27 +0200

Hello,

> time to post your views. I think it would reflect poorly on the WG if we

During the meeting, I was one of the few persons who raised a hand for
the TLV approach. I would like to shortly explain why.

First off, of course having existing implementations is good. One for
PT-EAP exists in FreeRADIUS, where I came across it. Something strange
has happened: even though this implementation was there, people who
tried out NEA decided to leave it aside and write a new extension to
FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as the
TLV approach, it is very similar in that it adds attributes to an
existing EAP method.
I also got to try out the SoH support in FreeRADIUS and it came very
natural, because it provides just yet-another-attribute to evaluate. I
came to like that approach; and, to be honest, quickly forgot about the
TNC library that would do PT-EAP.

Another argument that is being brought up occasionally is that PT-EAP
can be forwarded independently of the user authentication. That's
undoubtedly true (but one has to pay close attention to protect the
forwarding channel, so that NEA data isn't out in clear text!). But I
don't really see much use for that - in my view, user authentication and
the device the user is using are intrinsically linked together. In a
real-life example, yes, one can imagine that a policy "XP SP3 only"
exists, and that the NEA policy is offloaded to a different server than
the one which handles the authentication. But it is just as easily
imaginable that the policy *actually* says in fine-print: "But if it's
the CEO's device, don't get in his way even with SP1!" and/or "Only
users from the 'Art' department are allowed to bring MACs". That makes
for a NEA policy which depends on the user - which would require sending
user authentication information along with the NEA data, in order to
make a NEA policy decision. I don't think PT-EAP supports piggybacking
user-authentication information with NEA data in the PT-EAP datagram -
but I may be wrong, of course. I'd appreciate enlightenment :-)
The short conclusion of this overly long paragraph is: I think
authentication and and NEA evaluation belong together in significant
amounts of use cases; so why split them.

The third point is a small implementation one: PT-EAP needs many
technology prerequisites which are new and not widely deployed in my
experience: channel binding, EAP method chaining. It is a significant
implementation hurdle to get all that done right. Adding another
attribute to an existing RADIUS packet, OTOH, is rather simple, dare I
say trivial. I could imagine that NEA uptake in implementations will be
higher if the number of hoops to jump through is lower.

I'm well aware that my arguments above are not "hard facts" - I just
have a better feeling regarding the TLV ones. So, I absolutely don't
mind if my concerns get dismissed; but I wanted to raise them nonetheless.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 21 Jul 2011 10:26:57 -0400

Stefan,

I really appreciate your comments, especially since they are practical
and based on real-world experience, as are my own. One of the good things
about NEA is that we've all been solving this problem of endpoint assessment
for more than five years with a variety of techniques so we can bring to
bear a great deal of experience in what works and what doesn't, as well as
what's easy to implement and what's not.

I'm not surprised that some people chose to implement SoH support in
FreeRADIUS and use that instead of PT-EAP (EAP-TNC). Microsoft includes
SoH support in Windows XP SP3, Windows Vista, Windows 7, and Windows
Server 2008. That's an awfully large installed base! It's hard to ignore.
Most endpoint assessment vendors have implemented some sort of SoH
support, in response to customer demand. That doesn't mean we should
assume that SoH does everything right. In fact, the folks at Microsoft
have supported the NEA effort from the start. They took the lessons
learned from SoH (e.g. allow longer messages and multiple round trips)
and put them into PB-TNC.

You mentioned that SoH makes NEA into just another RADIUS attribute.
But none of the proposals here involve putting NEA messages into
RADIUS attributes. Instead, the NEA messages will be placed into an
EAP tunnel method. That's a good thing, since otherwise the NEA messages
could be flying around with little protection (e.g. no confidentiality).
In fact, Microsoft uses an EAP tunnel method (PEAP) to carry SoH when
it runs over EAP. RADIUS attributes are only used for SoH transport when
EAP is not available. So I don't think the idea of stuffing NEA messages
into RADIUS attributes is on the table in this discussion.

You raised a concern that PT-EAP requires channel binding. Both L2
PT proposals (PT-EAP and EAP-TLV) use TLS channel bindings only when
an External Measurement Agent like TPM is used for hardware-based
health checks. So there's no difference in the proposals for that.
And TLS channel bindings are only used when hardware-based health
checks are used. Anyone who's using hardware-based health checks is
already in the top .01% of the class in terms of sophistication,
at least today. So I wouldn't worry too much that they're going to
need to use TLS channel bindings. They're already on the cutting
edge of security technology. Anyway, it's the same for both proposals.

You make a good point about EAP method chaining. That is fairly new.
But I'm not convinced that handling extra TLVs passed in an EAP
tunnel method is any less novel. In fact, there has been a lot more
work done on analyzing the security properties of EAP method chaining
and improving that security than has been done with passing extra TLVs.
I'm not aware of any papers that analyze the security of passing extra
TLVs in an EAP tunnel method. There might be real security issues there.

I appreciate your comments on this. I don't want to dismiss them
but rather to take them seriously. We all want to create something
here that will be secure and easy to implement and deploy. Your
real-world experience is invaluable in that process. Thanks for
sharing it. I hope you understand that my comments above are all
intended to be constructive and helpful, aiming towards the same
goal that you also have.

Take care,

Steve

> Sent: Thursday, July 21, 2011 8:49 AM
> To: [email-masked]

---

From: Joe Salowey <[email-masked]>
Date: Thu, 21 Jul 2011 20:57:56 -0700

I'm still concerned that many implementations may not support EAP chaining.  I've been searching online trying to find out how current PT-EAP implementations support client authentication.  I haven't had much luck.  Can someone point me to some documentation that explains what sort of client authentication the current implementations support? 

Thanks,

Joe

---

From: Andreas Steffen <[email-masked]>
Date: Fri, 22 Jul 2011 06:51:29 +0200

Hello Joe,

strongSwan either uses certificate-based EAP-TLS client authentication
while setting up the outer EAP-TTLS tunnel that protects the
PT-EAP channel:

http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20-tls/carol.daemon.log

or uses the chain of EAP-Identity, followed by EAP-MD5/MSCHAPv2/GTC,
followed by PT-EAP within the outer EAP-TTLS tunnel:

http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20/carol.daemon.log

Regards

Andreas

On 07/22/2011 05:57 AM, Joe Salowey wrote:
> I'm still concerned that many implementations may not support EAP
> chaining.  I've been searching online trying to find out how current
> PT-EAP implementations support client authentication.  I haven't had
> much luck.  Can someone point me to some documentation that explains
> what sort of client authentication the current implementations
> support?
> 
> Thanks,
> 
> Joe On Jul 12, 2011, at 11:24 AM, Lisa Lorenzin wrote:
> 
>> Greetings!
>> 
>> Based on the meeting minutes and previous discussion thread, it
>> looks to me like a) there are pros and cons to each approach, and
>> b) either approach would accomplish the technical goals.
>> 
>> considerations take on greater significance.  Since PT-EAP has many
>> more technical implementations, and is based on an open standard
>> from TCG, it seems to better conform to the IETF's emphasis on
>> running code, and to better comply with the RFC 5209 requirement to
>> "prefer the reuse of existing open standards that meet the
>> requirements before defining new ones."
>> 
>> Based on those considerations, PT-EAP seems like a better choice.
>> 
>> Regards,
>> 
>> Lisa
>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Susan Thomson
>>> (sethomso) Sent: Thursday, June 30, 2011 18:31 To: [email-masked] 
>>> One of the outstanding items in the NEA WG is to come to
>>> consensus on whether to use EAP method or TLV for carrying NEA
>>> data in an EAP-based transport.
>>> 
>>> Steve Hanna has initiated a thread on this topic on the mailing
>>> list to which some have responded (see pointer below to email
>>> thread and to meeting minutes for summary of discussion at IETF
>>> 80).
>>> 
>>> We need more input from the WG to make a decision. Please review
>>> the pros and cons laid out in the thread and provide your input.
>>> Feedback may include any considerations that you think might be 
>>> missing from the discussion, as well how you would weigh the
>>> characteristics of the two approaches.
>>> 
>>> The deadline for making a decision is by the July IETF. If we do
>>> not, our AD has "offered" to make the decision for us! So please
>>> take the time to post your views. I think it would reflect poorly
>>> on the WG if we are unable to come to consensus ourselves.
>>> 
>>> Thanks Susan
>>> 

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

---

From: Stefan Winter <[email-masked]>
Date: Fri, 22 Jul 2011 14:57:19 +0200

Hello Steve, all,

thanks for these explanations, they are very helpful.

Could you bear with me one more time, please? It's about the one comment
that your reply didn't touch upon: Assume the authentication server and
NEA server are separate entities, and that the assessment result of a
machine varies depending in the user's identity (say, management is
allowed to drag behind one Windows Service Pack; or that certain machine
types are only tolerated for some user groups).

In that case, the NEA server needs to make different assessments
dependent on the user identity. Since it is not co-located with the
authentication server, PT-EAP needs to be forwarded to the NEA server.
How does the user identity information get to the NEA server, so that he
can make his assessment? Is it possible to blend parts of the preceeding
EAP (authentication) into the contents of the PT-EAP?

In particular, the information that is to be blended in would be the
inner identity as it was verified by the preceeding EAP method.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 22 Jul 2011 10:46:10 -0400

Stefan,

I don't know of any standard way to provide information about identity
from the authentication server to the NEA server.

I suppose that a standard RADIUS attribute could be defined to carry
this information, something like the IF-FTNC-User-Name-Identifier
attribute defined in the Federated TNC specification published at
http://www.trustedcomputinggroup.org/resources/federated_tnc_version_10_revision_26
However, that attribute was not defined for this exact use case and
I wouldn't propose that anything be done about this now. We have to
finish our work on the basic NEA specifications and this problem is
not part of our agreed-upon use cases for NEA.

I'd say that if you have placed your authentication server and your
NEA server on separate machines, you have effectively separated
the functions of authentication and posture checking. Still, the
authentication server could have a policy that says that because
of the user's identity or role, a failed posture check should not
block network access for that user. That's not unusual.

But I don't think there's any standard way when the authentication
server and the NEA server are separated in this manner to convey
user identity to the NEA server, at least not at this point. If you
want to perform different health checks depending on identity, you
should use a NEA server that's integrated with the authentication
server.

Thanks,

Steve

> From: Stefan Winter [mailto:[email-masked]]
> Sent: Friday, July 22, 2011 8:57 AM
> To: Stephen Hanna
> Cc: [email-masked]
> not,
> >>> time to post your views. I think it would reflect poorly on the WG
> if
> >> we
> >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale
> et
> >> de la Recherche

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 22 Jul 2011 11:25:50 -0400

Juniper supports several forms of EAP method chaining. We support
EAP-TTLS and PEAP with a variety of inner authentication methods
(EAP-MS-CHAP-V2, EAP-TLS, etc.) and several posture methods also.

For SOH compatibility, we support running several EAP methods within
PEAP: the SoH EAP Extensions Method followed by MS-CHAP-V2 and then
the SoH EAP Extensions Method again. I expect that anyone else who
supports SOH over EAP must also support EAP method chaining. That
means that Windows XP SP 3, Windows Vista, Windows 7, and Windows
Server 2008 would all include this code. Likewise the third-party
SOH agents from Avenda and UNETSystem, which run on Mac OS X, Linux,
and various old versions of Windows back to Windows 2000.

Of course, vendors don't generally provide a fully flexible system
for configuring arbitrary sequences of inner methods. But EAP method
chaining is often in there, under the hood.

Thanks,

Steve

> Andreas Steffen
> Sent: Friday, July 22, 2011 12:51 AM
> To: Joe Salowey
> Cc: [email-masked]

---

From: Stefan Winter <[email-masked]>
Date: Fri, 22 Jul 2011 21:19:15 +0200

Steve,

> from the authentication server to the NEA server.

Thanks for the clarification.

> not part of our agreed-upon use cases for NEA.

That reminds me a bit of the EAP-TLVs statements regarding "you could 
still forward the NEA data somehow, it's just not in the spec" :-)

It is really a pity that the use cases do not consider that a NEA 
server's assessment decisions could be dependent on the identity of the 
user. I think it is vital that it is *possible* to base such decisions 
on the connecting identity. And I think we all agree that a auth/NEA 
server combination that is not co-located is a plausible deployment 
(after all, in previous meetings and on the mailing list, it was seen as 
a big advantage of PT-EAP that it can be forwarded independently of the 
authentication payload).

Thinking about it, I think there is a possiblity to read something into 
the NEA Requirements to that effect, if we want to split a hair or two:

    C-2  NEA protocols SHOULD provide a way for both the NEA Client and
         the NEA Server to initiate a posture assessment or reassessment
         as needed.

"As needed" is (probably intentionally) an unspecific term. Assuming 
that a company policy says "Computers used by Marketing people need to 
be assessed twice as often as engineering's", the "as needed" includes a 
requirement that the NEA server knows which identities are behind a 
certain computing device, so that it can set its re-assessment timers 
appropriately.

Of course, saying that the NEA and auth server need to co-located in 
such a situation is an answer (but I don't think it has been articulated 
in the specs so far) - and it's not a very satisfying one, to be honest.

Saying that the transport of the user <-> NEA status bindings is out of 
scope is also an answer, but as I initially stated, this is a result 
that is on the same level as EAP-TLVs "wrapping NEA data to send off of 
the authentication server is out of scope" - I find none of the two 
terribly satisfying.

> should use a NEA server that's integrated with the authentication

That is a bit the crux: the need to co-locate these two servers for a 
specific use case can be seen as a specific shortcoming of PT-EAP; it is 
certainly not unavoidable in principle. The EAP-TLV proposal for example 
brings tieing of the auth+NEA data "built-in". This one goes too far, 
though:

- in EAP-TLV, auth+NEA data always comes bundled, and CANNOT be treated 
separately
- in PT-EAP, auth+NEA data always comes separately, and MUST be treated 
separately

(the requirements document does not require or even mention co-location 
of NEA and auth server, so I won't consider the argument "they could be 
co-located" here; we have to consider the general scenario[*])

That is a somewhat sad situation. The "ideal-world" protocol would 
*permit, but not mandate* to tie auth data and NEA data together, so 
that every possible deployment can deploy according to its needs.

So, I think both proposals are not where they could be. If there was a 
possibility to retrofit the lacking binding (when looking at PT-EAP) or 
lacking unbundling (in EAP-TLV), I think that would be desirable.

So much for late-evening wishful thinking :-)

Greetings,

Stefan Winter

[*] of course, EAP-TLVs requirement to put NEA data into an 
authentication payload is in itself awkward when looking at the 
requirements document - since authentication servers aren't mentioned at 
all, the requirement to pull-in a user-authentication EAP Type to 
transport the unrelated NEA data seems misplaced.

---

From: Paul Sangster <[email-masked]>
Date: Fri, 22 Jul 2011 15:53:20 -0700

The OpenSEA (Open1X) open source supplicant also supports several chaining variations of EAP methods.  The most common is PEAP / MSCHAPv2 / EAP-TNC.  Note that the Open1X supplicant has protocol support for PA-TNC and PB-TNC.

> Stephen Hanna
> Sent: Friday, July 22, 2011 8:26 AM
> To: Joe Salowey
> Cc: [email-masked]
> [email-masked]