On Feb 14, 2023, at 4:24 PM, John Scudder via Datatracker <nore...@ietf.org>
wrote:
> ### Section 3
>
> ```
> Earlier TLS versions did not always send application data along with
> the Finished message. It was then possible for implementations to
> assume that a receipt of a Finished message also meant that there was
> no application data available, and that another round trip was
> required.
> ```
>
> This doesn’t quite make sense to me as written. Do you mean that earlier TLS
> versions always did not send application data along with the Finished
> message?=
> Note the significant movement of the word "always". The way it’s written right
> now, "did not always" implies earlier TLS implementations "sometimes did" send
> application data along with the Finished message, and if that was the case, I
> don’t see how (non-buggy) implementations could make the assumption you note.
I think it's "always" did not send... I don't want to get into details of
TLS, but the EAP applications using TLS definitely assumed that "Finished"
meant "no application data".
I think the simplest thing to do here is to just remove "always":
Earlier TLS versions did not send application data along with the
Finished message.
> ### Section 4
>
> ```
> As the packet flows for resumption are essentially identical across
> all TLS-based EAP types, it is technically possible to authenticate
> using EAP-TLS (Type 13), and then perform resumption using another
> EAP type, just as EAP-TTLS (Type 21).
> ```
>
> Is “just as” in the last line, supposed to be “such as“? If “just as“ is
> correct, I don’t understand what’s intended.
Perhaps remove "just as":
Instead, this definition allows us to simplify references to EAP Types,
by using a logical "Type" instead of referring
> ### Section 6.1
>
> ```
> Similarly, when the inner authentication protocol indicates that
> authentication has succeeded, then implementations SHOULD cause
> authentication to succeed for the entire session. There MAY be
> additional protocol exchanges in order which could cause other
> failures, so success is not required here.
> ```
>
> That last sentence doesn’t make much sense to me. I am guessing what you mean
> is something like, “The reason success is not mandatory but only recommended
> in
> this case is that we cannot preclude that an inner protocol might have
> semantics such that authentication can succeed but the overall exchange still
> can fail.”
It's left over bits from multiple edits. Perhaps:
There MAY be
additional protocol exchanges which could still cause failure, so we
cannot mandate sending success on successful authentication.
> Feel free to use those words if they make sense, or not, but as the text
> stands
> I had difficulty so I suggest some kind of clarification. At a minimum, it
> appears to me that the words “in order” should be removed?
Yes.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
