On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith <[email protected]> wrote:
> Brian Smith <[email protected]> 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 >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
