Subject: [Nea] Comments on running PT-EAP outside the tunnel

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Feb 2012 21:00:57 -0800

At the IETF meeting we had some discussion of whether to allow PT-EAP outside of the protection of a EAP tunnel method.  

I think PT-EAP should always be run inside the protection of a Tunnel method.  The method itself is insecure and does not provide authentication without a tunnel method.   This would be a large step backwards in the security of deployments if it is used without the protection of a tunnel method.  

Another reason given for allowing PT-EAP to be used without a tunnel is to proxy the clear test PT-EAP method through a AAA proxy chain.  This is insecure.  Standard AAA proxies do not look into the EAP method attribute, they just proxy it on to the next hop without additional protection. This will leave the PT-EAP method in the clear.  

For these reasons the PT-EAP specification should prohibit the use of PT-EAP outside an EAP  tunnel method. 

Cheers,

Joe

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 10 Feb 2012 14:23:55 -0500

Joe,

Thanks for raising this issue again. We have discussed it in
the past but I don't think we have reached WG consensus yet.
I hope that we can reach WG consensus on it soon!

You and I had a thorough discussion of this topic last August
on the nea list under the subject "Protecting L2 PT when proxying".
People may wish to review that discussion in our archives at
http://www.ietf.org/mail-archive/web/nea/current/msg01169.html
(and the rest of the messages in the thread). Some things have
changed since August (e.g. the selection of PT-EAP as our L2
PT) but most of the discussion is still relevant.

I think the current PT-EAP draft reflects the general WG
consensus that PT-EAP should run inside an EAP tunnel method.
The only remaining question seems to be whether we should
permit PT-EAP to be used outside an EAP tunnel method at any
time. The current draft does not include a prohibition on such
behavior or an equivalent requirement that PT-EAP MUST be
always carried in an EAP tunnel method. I believe that you're
arguing that we should add such a prohibition or requirement.

Stefan Winter emailed the NEA list in late July with a desire
to support a proxying use case where authentication and
posture checking would be performed on separate servers.
This would argue for permitting PT-EAP outside of an EAP
tunnel method (maybe with RADSEC). However, Stefan also
wanted a standard way to convey the user's identity to
the posture checking server. That's not supported by our
current design. And Stefan's use case is not in RFC 5209.

So my conclusion is that I'm OK with adding a requirement
in PT-EAP that PT-EAP MUST always be carried in an EAP
tunnel method. 

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joe Salowey
> Sent: Friday, February 10, 2012 12:01 AM
> To: [email-masked]
> Subject: [Nea] Comments on running PT-EAP outside the tunnel
> 
> At the IETF meeting we had some discussion of whether to allow PT-EAP
> outside of the protection of a EAP tunnel method.
> 
> I think PT-EAP should always be run inside the protection of a Tunnel
> method.  The method itself is insecure and does not provide
> authentication without a tunnel method.   This would be a large step
> backwards in the security of deployments if it is used without the
> protection of a tunnel method.
> 
> Another reason given for allowing PT-EAP to be used without a tunnel is
> to proxy the clear test PT-EAP method through a AAA proxy chain.  This
> is insecure.  Standard AAA proxies do not look into the EAP method
> attribute, they just proxy it on to the next hop without additional
> protection. This will leave the PT-EAP method in the clear.
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stefan Winter <[email-masked]>
Date: Mon, 13 Feb 2012 14:44:53 +0100

Hi,

> For these reasons the PT-EAP specification should prohibit the use of PT-EAP outside an EAP  tunnel method.

I agree that sending PT-EAP unprotectedly is a bad idea and should be 
prohibited.

I'm not sure that the protection necessarily has to be with an EAP 
tunnel method though.

We've discussed earlier that there might be a use case in blending 
identity information with posture assessments and sending that to a 
policy server.

If the data that's transferred on that leg is protected *somehow*, that 
would already be quite satisfactory to me.

E.g. I could imagine that an EAP server terminates the tunnel method, 
authenticates the user, extracts posture information, *sends that over a 
TLS link to the policy server*, and decides on user admissability based 
on the policy server's results.

Note how the posture data is protected by TLS just fine; it's just not 
an EAP tunnel method.

I don't think we should preclude that kind of thing from happening. So 
I'd reformulate your statement above to:

"should prohibit the use of PT-EAP outside a cryptographically protected 
tunnel (e.g. an EAP tunnel method)"

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: Stefan Winter <[email-masked]>
Date: Tue, 14 Feb 2012 08:24:53 +0100

Hi,

> tunnel (e.g. an EAP tunnel method)"

following up on myself: I guess I was slightly wrong :-)

It is important to send assessment data via a protected channel, that is 
IMHO still valid.

It is not important that this assessment data be encoded in PT-EAP 
though: the entity that terminates the EAP tunnel decodes assessment 
data from PT-EAP. If it decides it needs to send the assessment data 
and/or associated identity data elsewhere, this can be encoded 
arbitrarily (so long as the communication is encrypted (do we all agree 
on this?).

The communication would have to include the actual assessment data (PA 
messages) but would otherwise not have anything to do with the PT-EAP 
transport.

With the payload data and the transport being considered differently, 
it's easy to state how things should be:

* Joe's "should prohibit the use of PT-EAP outside an EAP  tunnel 
method." is just fine.

* A protocol is needed to transport assessment data (PA) and associated 
identity information from the EAP server to a policy server.

This moves the problem out of the realm of EAP. It does raise the 
question though: what protocol would that be? I don't think there is a 
standardised protocol to do exactly that. PT-TLS comes to mind, but it 
doesn't cope with the identity parts.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473