Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M <mohit.m.sethi@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 <joe@salowey.net> wrote:
>
>>
>>
>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar <oleg.pekar.2017@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 <joe@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
>
>