<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith <span dir="ltr"><<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Brian Smith <<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</a>> wrote:<br>
> Although the RFC4851 (an informational RFC documenting EAP-FAST) does<br>
> not require the server to send the session ticket extension during<br>
> resumption, it is based on RFC4507/RFC5077 (which are on the standards<br>
> track), which *does* require the server to send the extension. So,<br>
> this is a bug in the non-conformant servers, not in the openssl<br>
> client.<br>
<br>
</span>Sorry. It seems I am wrong about this. RFC 5077 says "It is also<br>
permissible to have an exchange similar to Figure 3 using the<br>
abbreviated handshake defined in Figure 2 of RFC 4346, where the<br>
client uses the SessionTicket extension to resume the session, but the<br>
server does not wish to issue a new ticket, and therefore does not<br>
send a SessionTicket extension."<br>
<br>
AFAICT this means that, even outside of EAP-FAST, it is allowed for<br>
the server to resume a session using a session ticket without sending<br>
the session ticket extension in its ServerHello message.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Also, note that RFC 5077 section 3.4 allows the client to use a<br>
session ticket and an empty session ID to resume a session, instead of<br>
generating a "fake" session ID for the session ticket: "Alternatively,<br>
<span>the client MAY include an empty Session ID in the ClientHello.  In<br>
this case, the client ignores the Session ID sent in the ServerHello<br>
and determines if the server is resuming a session by the subsequent<br>
handshake messages."<br>
<br>
</span>If OpenSSL's client code were changed to always use an empty session<br>
ID when attempting resumption using a session ticket, then the<br>
EAP-FAST case wouldn't be different from the general session ticket<br>
resumption case. I think that this is a cleaner approach.<br></blockquote><div><br></div><div>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.<br></div><div> </div><div>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 </div><div>issue behind it.</div><div><div><br></div><div>But thanks a lot for diving into the RFCs!  A second pair of eyes is very much needed here.</div><div><br></div><div>Cheers,</div><div>Emilia</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Note that RFC4851 would likely still need to be updated, because TLS<br>
1.3 will most likely remove the ChangeCipherSpec messages, and<br>
RFC4851's recommended resumption detection is based on detecting<br>
ChangeCipherSpec messages.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
Cheers,<br>
Brian<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</div></div></blockquote></div><br></div></div>