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

2021-07-08 Thread Alan DeKok
On Jul 8, 2021, at 12:42 PM, Joseph Salowey  wrote:
> 
> I created PR that I think captures these suggestions and another editorial 
> fix - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/87

  I think it looks good.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-07-08 Thread Joseph Salowey
I created PR that I think captures these suggestions and another editorial
fix - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/87

Cheers,

Joe

On Thu, Jul 8, 2021 at 9:36 AM Oleg Pekar  wrote:

>
>
> On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M 
> 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  wrote:
>>
>>>
>>>
>>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
>>> 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  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=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


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

2021-07-08 Thread Oleg Pekar
On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M 
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  wrote:
>
>>
>>
>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
>> 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  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=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


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

2021-07-08 Thread Joseph Salowey
On Thu, Jul 8, 2021 at 6:11 AM Alan DeKok  wrote:

> On Jul 8, 2021, at 2:52 AM, tom.ri...@securew2.com wrote:
> > Maybe this has been discussed already, but we often see the need for
> multiple root cas when people are migrating the root CA of their RADIUS
> server. They would then configure both the old and new Root CA in the
> client to allow seamless transition.
>
>   Yes, that makes sense.  Perhaps instead:
>
> SHOULD allow for the configuration of one or more trusted root (CA
>certificates)
>
>
[Joe] Yes good catch


>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-07-08 Thread Alan DeKok
On Jul 8, 2021, at 2:52 AM, tom.ri...@securew2.com wrote:
> Maybe this has been discussed already, but we often see the need for multiple 
> root cas when people are migrating the root CA of their RADIUS server. They 
> would then configure both the old and new Root CA in the client to allow 
> seamless transition. 

  Yes, that makes sense.  Perhaps instead:

SHOULD allow for the configuration of one or more trusted root (CA
   certificates) 

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-07-08 Thread tom.rixom
>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." 

Hi,


I am not sure if I am allowed to respond on this but is the spec now 
restricting it to 1 “unique trusted root root (CA certificate)”?

Maybe this has been discussed already, but we often see the need for multiple 
root cas when people are migrating the root CA of their RADIUS server. They 
would then configure both the old and new Root CA in the client to allow 
seamless transition. 

Thanks,

Tom
SecureW2

 

From: Emu  On Behalf Of Mohit Sethi M
Sent: Thursday, July 8, 2021 7:31 AM
To: Joseph Salowey ; Oleg Pekar 
Cc: EMU WG 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 
(draft-ietf-emu-eap-tls13-17)

 

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 mailto:j...@salowey.net> > wrote:

 

 

On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar mailto: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

 

Regards,

Oleg

 

On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey mailto: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 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-emu-eap-tls13-17=draft-ietf-emu-eap-tls13-15>
 =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 <mailto:Emu@ietf.org> 
https://www.ietf.org/mailman/listinfo/emu





___
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org> 
https://www.ietf.org/mailman/listinfo/emu



smime.p7s
Descript

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

2021-07-07 Thread Mohit Sethi M
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 
mailto:j...@salowey.net>> wrote:


On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
mailto: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


Regards,
Oleg

On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey 
mailto: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=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 list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-07-07 Thread Joseph Salowey
On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey  wrote:

>
>
> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
> 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."


>
> [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.
>
>
>> Regards,
>> Oleg
>>
>> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  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=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 list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-07-06 Thread Joseph Salowey
On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
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] 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.


> Regards,
> Oleg
>
> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  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=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 list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-06-28 Thread Oleg Pekar
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.

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

Regards,
Oleg

On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  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=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 list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-06-27 Thread Joseph Salowey
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=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