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

[Alan DeKok <[e-mail]>]

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.

  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?

  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.

>>   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.

>>> 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.

>>   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

>>> 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.

>> 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]"

> 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

  Alan DeKok.