[openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith <brian at briansmith.org> wrote:

> Brian Smith <brian at briansmith.org> wrote:
> > Although the RFC4851 (an informational RFC documenting EAP-FAST) does
> > not require the server to send the session ticket extension during
> > resumption, it is based on RFC4507/RFC5077 (which are on the standards
> > track), which *does* require the server to send the extension. So,
> > this is a bug in the non-conformant servers, not in the openssl
> > client.
>
> Sorry. It seems I am wrong about this. RFC 5077 says "It is also
> permissible to have an exchange similar to Figure 3 using the
> abbreviated handshake defined in Figure 2 of RFC 4346, where the
> client uses the SessionTicket extension to resume the session, but the
> server does not wish to issue a new ticket, and therefore does not
> send a SessionTicket extension."
>
> AFAICT this means that, even outside of EAP-FAST, it is allowed for
> the server to resume a session using a session ticket without sending
> the session ticket extension in its ServerHello message.
>

Correct, but outside EAP-FAST we use the session ID to detect if we're
resuming. Honouring the synthetic session ID is a MUST in RFC5077.

I have asked, in a separate thread with Erik, whether EAP-FAST servers
would honour the session ID (so we could set it and detect resumption based
on that) but the answer appears to be "no".


> Also, note that RFC 5077 section 3.4 allows the client to use a
> session ticket and an empty session ID to resume a session, instead of
> generating a "fake" session ID for the session ticket: "Alternatively,
> the client MAY include an empty Session ID in the ClientHello.  In
> this case, the client ignores the Session ID sent in the ServerHello
> and determines if the server is resuming a session by the subsequent
> handshake messages."
>
> If OpenSSL's client code were changed to always use an empty session
> ID when attempting resumption using a session ticket, then the
> EAP-FAST case wouldn't be different from the general session ticket
> resumption case. I think that this is a cleaner approach.
>

1)  The way EAP-FAST diverges from 5246 and 5077 is indeed quite
unfortunate. The lookahead is messy, and hard to get right - I don't want
another "early CCS" due to lack of determinism in the state machine.
Setting the session ID is much cleaner. So, I'd rather put in a workaround
that is specific to EAP-FAST and doesn't affect regular handshakes.

2) Removing the session ID upon resumption would be a big change in
behaviour that I don't think would qualify for a stable branch anyway
unless there was a security or regression
issue behind it.

But thanks a lot for diving into the RFCs!  A second pair of eyes is very
much needed here.

Cheers,
Emilia



> Note that RFC4851 would likely still need to be updated, because TLS
> 1.3 will most likely remove the ChangeCipherSpec messages, and
> RFC4851's recommended resumption detection is based on detecting
> ChangeCipherSpec messages.


> Cheers,
> Brian
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150330/ab3a0cb9/attachment.html>