eap Mailing List: Re: Issue 218: TLS example

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:
> > It worries me that the RFC may not be clear on this. If its not,
> > there can be implementations that do it in another manner than
> > you assume. I agree it would make sense to do it as you explain,
> > but maybe the implementor has read Section 3.8... Anyway, this
> > is not a 2284bis issue. But we should keep that in mind for a
> > possible future update of the EAP-TLS RFC or in discussions
> > of what protection exists in EAP.
>
>
> I've checked the TLS RFC, and there is no problem with ending a TLS alert

Thanks for digging into this.

> at any point after data transmission has commenced.  So the example in RFC
> 2716 is ok.  An alert can be sent before or after the server FINISHED
> message, and could even be sent by the client in response to the server
> FINISHED message (as opposed to the null packet illustrated).  SSL/TLS
> APIs typically enable alerts to be sent at any time, too.

Well, that's good for RFC 2716 because then its example is
correct. Its also good that APIs have the capability, because
then implementations can provide the alerts at the
most appropriate time.

But I wonder if this is good or bad for the discussion
on EAP protected indications. If the alerts can be sent at
any time, then we do not have a guarantee that they
are sent before FINISHED, as our current proposed text
says. * **

Here's a proposed fix. Replace

  A protocol may provide protected result indications in some
  circumstances, but not in others. For example, within
  EAP-TLS [RFC2716], in the full handshake the peer intially authenticates
  the server, and sends a TLS alert message in the event of an
  authentication or authorization failure. If the server does not
  receive a TLS alert message from the peer and the peer continues the
  conversation to completion (e.g. sends a FINISHED message), then the
  server can assume that the peer will accept access if granted it by
  the server.

with

  A protocol may provide protected result indications in some
  circumstances, but not in others. For example, within
  EAP-TLS [RFC2716], in the full handshake the peer intially authenticates
  the server, and sends a TLS alert message in the event of an
  authentication or authorization failure. If the server does not
  receive a TLS alert message from the peer and the peer continues the
  conversation to completion, then the server can assume that the
  peer will accept access if granted it by the server.

--Jari

*) In fact, looking at Section 3.8 of RFC 2716, it
seems that in the examples, the alerts are sent at a
position where you would expect either Success, an
empty EAP-TLS packet, or an alert. Since both Success
and empty EAP-TLS packets can be spoofed, attackers can
spoof the lack of an alert, leading to DoS. Or am I
reading the draft wrong? What does this mean:

                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS

Is it a an empty EAP-TLS packet without TLS record inside,
TLS Message Length set to 0? Or an EAP-TLS packet with
an empty TLS record inside?

**) Another EAP-TLS question: if you compare examples in 2 and
3 in Section 3.8, the parts that happens after the server sends
a FINISHED message are very similar. In both cases the peer sends
an empty TLS record. In example 2 the server responds with EAP
Success, and in example 3 the server responds with an alert.
The peer must then be prepared to receive either a protected
alert or an unprotected success, or?