John: Thanks Jouni, very good comments. Great to get feedback from
implementation. I think there is a slight mismatch between the assumptions in
TLS and EAP, in TLS the connection is assumed to stay open for a long time after
the client sends Finished, in EAP the connection is assumed to be closed shortly
after.
> Based on implementation experiment of this (or well, the previous draft, so
> with the old labels), the most inconvenient part of this design was the way
> the session resumption is handled in TLS v1.3. When that is mapped to
> EAP-TLS in the way it is in this draft, the peer has no idea whether the
> NewSessionTicket is delivered after ClientFinished. In other words, the
> next message in the sequence could be either continuation of EAP-TLS method
> or EAP-Success. This means that the peer cannot use methodState=DONE,
> decision=UNCOND_SUCC per RFC 4137 state machine whenever using TLS v1.3
> (while being able to continue to use that combination with TLS v1.0, v1.1,
> and v1.2). Instead, for TLS v1.3, methodState=MAY_CONT, decision=COND_SUCC
> needs to be used. While this may not sound very critical, it was a bit
> inconvenient to have make that behavior conditional on the TLS version.
John: In general, a TLS 1.3 server could send several NewSessionTicket before
sending EAP-Success. Theoretically, the Peer and Server may also exchange other
Post-Handshake Messages (Section 4.6 in TLS 1.3) after the main handshake but
before the EAP-Success. One option would to restrict EAP-TLS to a subset of TLS,
but that could also make it incompatible with future extensions. Based on your
comments, the draft may need to specify which Post-Handshake messages that can
be sent in EAP-TLS.
> Would there be any way of avoiding this uncertainty about the next message
> on the client side within the EAP-TLS method itself?
John: EAP-TLS Request and Response packets have a byte called ‘Flags’ with 5
reserved bits that could be used if it helps.
Flags
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|L M S R R R R R|
+-+-+-+-+-+-+-+-+
One of the bits could be used to signal information from the EAP Server to the
EAP Peer. But I think the meaning of the bit would need some analysis in that
case, I am not certain that the TLS server knows whether it will send more
EAP-Requests before receiving the Finished message from the TLS client. Another
question is how much information the EAP-TLS layer gets from the TLS layer.
> If not, I might as
> well as bring up another comment regarding the extra round trip from this
> NewSessionTicket delivery. That does not look very efficient. If we would
> not care about layering between the EAP method and EAP peer/server
> implementation, NewSessionTicket could actually be piggybacked on top of
> the EAP-Success message.. Sure, that would require a change in the
> EAP-Success definition, but this would remove this undesired uncertainty
> about the next message in the sequence and would get rid of one extra
> roundtrip in the exchange which could be a significant reduction in overall
> latency for the handshake.
John: Interesting suggestion, I think reducing latency is certainly worthwhile,
but as you say it would require an update to RFC 3748. I think this is something
we should discuss on the list and in Montreal.
> Having to change the MSK/EMSK derivation just for the sake of getting a new
> label string into use based on the TLS version is also a bit inconvenient.
> This is obviously assuming that the previous implementation was already
> using TLS-Exporter interface. In general, it would have been nicer if
> existing EAP-TLS implementations would work simply by updating the TLS
> implementation from v1.2 to v1.3.
John: Good comments. The main goal is to exactly define how to derive the keys
when using TLS 1.3. The key derivation has been causing interoperability
problems for EAP-TLS. Let's discuss what the best tradeoff is based on
implementation convinient, what the API is supposed to be between TLS and
EAP-TLS, and security.
As far as I can see the derivation of Key_Material in RFC 5216 is compatible
with the Exporter interface defined in RFC 5705. A definition like:
Key_Material = TLS-Exporter("client EAP encryption", null, 128)
could potentially work for all versions of TLS and be compatible with RFC 5216.
This definition would use the master_secret for TLS 1.0 -- TLS 1.2 and the
exporter_master_secret for TLS 1.3.
The Session-ID definition could potentially stay the same, i.e. the EAP Peer and
EAP Server reads 32 bytes at TLS_Data[6] to get the random numbers.
The derivation of the IV in RFC 5216 is however not compatible with the
TLS-Exporter interface (as far as I see) as it uses the PRF with an empty key.
What API are we assuming between EAP-TLS and TLS? To use the PRF directly,
EAP-TLS needs to be aware of both the TLS version and the negotiated PRF. Not
using a standardized API could definitely lead to combability problems in the
future. E.g. if someone standardizes something like
https://tools.ietf.org/html/draft-rescorla-tls-extended-random
While public IVs used to be the norm, deriving a secret IV is now becoming the
default (TLS 1.3, QUIC, OSCORE)
> Anyway, if any one of these change is
> going to be needed in the end, the EAP method implementation will need to
> be made aware of the negotiated TLS version and other changes are coming
> with somewhat reduced implementation complexity.
John: Your earlier comments seem to indicate the EAP-TLS needs to be aware of
the negotiated TLS version to handle the quite different message flows. And if
the EAP-TLS implementation knows the TLS version, the key derivation could be
updated as well. If the EAP-TLS implementation does not need to be
aware of the TLS version to handle the different message flows, then other
tradeoffs might be better.
Based on this discussion I think it would be good to agree and write down the
assumptions on how the interface between TLS and EAP-TLS is supposed to look
like.
Cheers,
John
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
