Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

[Joseph Salowey <[e-mail]>]

On Fri, Jun 11, 2021 at 11:29 AM Alan DeKok <[e-mail]>
wrote:

> On Jun 11, 2021, at 2:12 PM, Mohit Sethi M <[e-mail]>
> wrote:
> > The comment here says adding text about "TLS version negotiation". There
> > is a comment from you below saying: "I don't understand why it's
> > necessary to include discussion of TLS negotiation in EAP, when that
> > negotiation does not affect EAP in any way." Am I missing something or
> > is there conflicting feedback?
>
>   There are two unrelated issues here.
>
>   It would be good to explain why EAP-TLS 1.3 is compatible with earlier
> versions of EAP-TLS.  This compatibility is done by EAP-TLS *implicitly*
> relying on TLS for version negotiation.
>
>   i.e. there is no version in the EAP-TLS header.  And EAP-TLS has no
> provisions for version negotiation outside of TLS.
>
>
[Joe]  The existing text already refers to relying on the underlying TLS
version negotiation.



>   The later comments about other TLS negotiation are for other handshake
> messages, and are entirely unrelated to version negotiation.
>
>   TLS has a large number of handshake messages which can be exchanged.
> Section 2.1.6 calls out HelloRetryRequest as special, but with no
> explanation as to why.  There is no discussion that the HelloRetryRequest
> affects EAP-TLS in any way.  As such, I ask again why is the text about
> HelloRetryRequest included in the document.  And if the EAP-TLS
> specification needs to discuss HelloRetryRequest, why not also include a
> section for every handshake message used by TLS?
>
>
[Joe]  I don't see a problem with covering new TLS handshake messages in
the document, however they are covered somewhat inconsistently.  Perhaps we
should cover them all in a "new handshake messages section".

TLS 1.3 introduces several new handshake messages including
HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages
will be handled by the underlying TLS libraries and are not visible to
EAP-TLS, however there are a few things to note.

The HelloRetryRequest is used by the server to reject the parameters
offered in the ClientHello and suggest new parameters.  When this message
is encountered it will increase the number of round trips used by the
protocol.

The NewSessionTicket message is used to convey session
resumption information and is covered in sections 2.1.2 and 2.1.3.

The KeyUpdate message is used to update the encryption keys used on a TLS
connection.  EAP-TLS does not encrypt significant amounts of this data so
this functionality is not needed.  Implementations SHOULD NOT send this
message, however some TLS libraries may automatically generate and process
this message.   (remove current text on KeyUpdate)



>   Does Section 2.1.6 mandate any behavior for EAP-TLS implementations?  If
> the text in Section 2.1.6 doesn't require EAP-TLS implementations to do
> anything, then that section can be omitted without any issue.
>
> >>> e.g. The "no peer authentication" situation MUST NOT be used to give
> >>> normal network access to EAP peers.  Instead, deployments SHOULD
> >>> provide access which is limited in both time, and in capability.
> >>> Usually this means a "quarantine" network, or "walled garden", which
> >>> has only limited capability.
> > There is text already in the draft which says : "While the EAP server
> > SHOULD require peer authentication, this is not mandatory, since there
> > are circumstances in which peer authentication will not be needed (e.g.,
> > emergency services, as described in [UNAUTH]), or where the peer will
> > authenticate via some other means.". This is what was said also in RFC
> > 5216. We also have also have the following text in the draft: "Some
> > deployments may permit no peer authentication for some or all
> > connections.  When peer authentication is not used, implementations MUST
> > take care to limit network access  appropriately for unauthenticated
> > peers and implementations MUST use resumption with caution to ensure
> > that a resumed session is not granted more privilege than was intended
> > for the original session.". I think we have tried to find a careful
> > balance between providing sufficient guidance vs. being repetitive. Is
> > there something that should be repeated in section 2.1.5?
>
>   The common terms used for limited access networks include "walled
> garden" and "quarantine network".  Using these terms would both make it
> clear to the reader what is expected, and reiterate that these well-known
> processes are being required here.
>
>   i.e. "take care to limit network access  appropriately" gives
> insufficient guidance for an implementor.  "taking care" is not an
> actionable recommendation.  In contrast, asking people to "enable your
> vendors walled garden functionality" is actionable.
>
>
[Joe]  OK how about adding:

"An example of limiting network access would be to invoke a vendor's walled
garden or quarantine network functionality."


> >>   I don't understand why it's necessary to include discussion of TLS
> negotiation in EAP, when that negotiation does not affect EAP in any way.
> > See above.
>
>   In short: TLS version negotiation does affect EAP-TLS.
> HelloRetryRequest messages do not.
>
>
[Joe] The EAP TLS layer needs to know which TLS version was negotiated.
HelloRetryRequests affect the number of round trips in the exchange, but
are opaque with respect to EAP-TLS.


> >>> Question: if the EAP-TLS implementation can do nothing other than ask
> >>> the TLS layer to continue the handshake, is this section even
> >>> necessary or relevant?
> > This section was added based on a review by Jim Schaad
> > (https://mailarchive.ietf.org/arch/msg/emu/qO5qgQ-8GzB-jVx2vtrQCe42cCg/).
>
> > If nothing else, I would like to keep it as a homage to him.
>
>   That's good, but the section needs to have actionable text.  i.e. what
> do implementors do here?
>
>   The recommendation in the above link says "Alternatively state that
> HelloRetryRequest MUST NOT be used (or positively that the server MUST
> respond with ServerHello)"
>
>   Those recommendations are actionable.
>
>
[Joe]  HelloRetryRequest is a feature of the underlying TLS library so the
RFC8446 Should determine the underlying behavior, specifying a different
behavior is problematic.



> >>   The updated text is clearer, but still does not address some of the
> questions raised below about calling this out as a new requirement from
> 5216, and what happens in an HA environment.
> > Please let us know a good reference to "implementation and
> > interoperability experience." about the upper limit on EAP packet
> > exchanges. This would also be useful for draft-ietf-emu-eaptlscert.
>
>   I posted references on this list previously:
>
> https://mailarchive.ietf.org/arch/browse/emu/?qdr=y
>
>
[Joe] I think this is the wrong link.


> >>> Requiring a supplicant to be configured with a peer name is a new
> requirement from RFC 5216, and isn't called out as such.
> > I agree with you that we could benefit from more clarification on
> > relationship between section 2.2 and 5.2 of this draft vs. the old RFC
> > 5216. Do you have a suggestion how best to split the text and reflect
> > the updates to RFC5216?
>
>   Updating 2.2 with a note after the text on page 18 seems best:
>
> While this requirement to verify domain names is new, and was not
> mentioned in [RFC5216], it has been widely implemented in EAP peers.  As
> such, we believe that this section contains minimal new interoperability or
> implementation requirements on EAP peers.
>
>
[Joe] This does not seem to add to the specification.


> >> Unaddressed without any comment or discussion:
> >>
> >>> Section 5.1 says:
> >>>
> >>>  [4] Cryptographic Negotiation: TLS 1.3 increases the number of
> >>>  cryptographic parameters that are negotiated in the handshake.  When
> >>>  EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
> >>>  negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
> >>>  groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
> >>>
> >>> Question: what does this mean in practice for EAP-TLS?  i.e. this text
> >>> describes a capability.  It does not describe what that capability
> >>> does, or how it benefits EAP-TLS.
> > This is what RFC5216 said "EAP-TLS inherits the secure ciphersuite
> > negotiation features of TLS, including key derivation function
> > negotiation when utilized with TLS v1.2 ". Do you have some suggestion
> > on what we should add?
>
>   I am wary of repeating text about negotiation, which might be
> inconsistent with the parent reference.  The text isn't wrong, but it may
> be worth just saying something to the effect of "EAP-TLS does not do
> cryptographic negotiation, but instead relies on TLS.  See Section 4.1.1.
> of [RFC8446]"
>
>
[Joe] The text included in the draft is fairly minimal.  I think the
suggestion is good since these are internal details of TLS, but I don't
think it is necessary.


> > Could you also highlight if there are some unaddressed comments. It
> > wasn't obvious if "Unaddressed without any comment or discussion:"
> > refers only to the discussion immediately below or to several
> > discussions below.
>
>   It refers to all of the discussions below, until the next comment of
> "addressed".  So there are still unaddressed comments.  Specifically,
> comments on Sections 2.1.1 (post handshake KeyUpdate), Section 5.2, 5.3,
> and 5.4
>
>
[Joe] See suggestion for new handshake messages above.




>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>