On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M <mohit.m.se...@ericsson.com> wrote:
> Hi Oleg, Joe, all, > On 7/8/21 8:06 AM, Joseph Salowey wrote: > > > > On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey <j...@salowey.net> wrote: > >> >> >> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar <oleg.pekar.2...@gmail.com> >> wrote: >> >>> I still see unclearness in Section "2.2. Identity Verification", I'm >>> trying to look from the implementer's perspective. >>> >>> 1) "Since EAP-TLS deployments may use more than one EAP >>> server, each with a different certificate, EAP peer implementations >>> SHOULD allow for the configuration of a unique trusted root (CA >>> certificate) to authenticate the server certificate and one or more >>> server names to match against the SubjectAltName (SAN) extension in >>> the server certificate. To simplify name matching, an EAP-TLS >>> deployment can assign a name to represent an authorized EAP server >>> and EAP Server certificates can include this name in the list of SANs >>> for each certificate that represents an EAP-TLS server." >>> >>> --- question: Should the server name match *any* of SAN extensions in >>> the server certificate? If so - then suggest to say this explicitly. >>> >>> > [Joe] DOes adding the following sentence help? > > "If any of the configured names match any of the names in the SAN > extension then the name check passes." > > This makes sense. I will update the draft in github. > > > >> >> [Joe] yes the behavior is to match any. >> >> >>> 2) "If server >>> name matching is not used, then peers may end up trusting servers for >>> EAP authentication that are not intended to be EAP servers for the >>> network." >>> >>> --- question: It looks like a warning, right? Suggest to make it more >>> explicit. Something like "If server name matching is not used, then it >>> essentially decreases the level of security of peer's authentication since >>> the peer may end up trusting servers for EAP authentication that are not >>> intended to be EAP servers for the network." >>> >>> >> [Joe] Thanks, I think that is better wording. >> > I find the text a little hard to parse. I am not sure how comfortable we > are with defining "levels" of security. Also, "peer's authentication" might > confuse the reader since we are talking about server name matching. I don't > really have a better suggestion. Perhaps something along the lines: .... it > essentially degrades the peer's confidence that the EAP server with which > it is interacting is authoritative for the given network....?? > Mohit, this wording makes sense, thanks! --Mohit > > >> >>> Regards, >>> Oleg >>> >>> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey <j...@salowey.net> wrote: >>> >>>> This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13. >>>> Please review the draft, focus on the changes since the last WGLC and >>>> submit your comments to the list by July 8, 2021. >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ >>>> >>>> There is also an htmlized version available at: >>>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17 >>>> >>>> A diff from the previous WGLC version (-15): >>>> >>>> https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17 >>>> >>>> Thanks, >>>> >>>> Joe >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>>> >>> > _______________________________________________ > Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu