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

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

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

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

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

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

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

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

[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&url2=draft-ietf-emu-eap-tls13-15>
 &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 <mailto:Emu@ietf.org> 
https://www.ietf.org/mailman/listinfo/emu





___
Emu mailing list
Emu@ietf.org <mailto:Emu@ietf.org> 
https://ww

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

[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&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 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)

[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&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 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)

[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&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 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)

[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&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 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)

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

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Alan DeKok]

On May 16, 2021, at 2:30 PM, Joseph Salowey  wrote:
> This is under-stating the issue rather severely.  We know with
> absolute certainty that most (if not all) EAP implementations and
> access networks limit the number of EAP packet exchanges.  Perhaps
> update the text to reference implementation and interoperability
> experience.
> 
> [Joe] Is there a paper that should be referenced?

  No papers that I recall.  But source code to hostap and FreeRADIUS is 
publicly available.  I've previously posted stable links to specific revisions 
of the source, for both projects.

> 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.
> 
> [Joe] Although this is an internal TLS detail I don't see any problem 
> discussing this in the security considerations. 

  I don't see it's a problem, but I don't know why it's there.  Should the 
EAP-TLS document discuss all of the properties of TLS?  If not, then perhaps a 
subset?  And which subset to pick?

  As an implementor, anything which is explicitly called out in the document 
should be there for a reason.  i.e. to guide implementors.  So reading the 
above text leads me to conclude that the text is important.  But there are no 
actionable items coming from that text.  No recommendations, and no further 
discussion.

  And the first sentence is truncated from a grammatical sense:  "TLS 
increases..." as compared to what?

  Perhaps it's simpler to just say:

 [4] Cryptographic Negotiation: Compared to earlier versions, TLS 1.3 increases 
the number of
 cryptographic parameters which are negotiated in the handshake.  When
 EAP-TLS is used with TLS 1.3, EAP-TLS inherits all of the increased 
capabilities of TLS.  See Section 4.1.1 of [RFC8446] for more information.

> [Joe]  How about 
> 
> "When peer authentication is not used, deployments
>MUST take care that the resulting access granted by AAA servers and 
> network authenticators is appropriate for
>unauthenticated peers."

  Yes.

  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

[Joseph Salowey]

On Thu, May 6, 2021 at 12:11 PM Alan DeKok 
wrote:

>
>
> > On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> >
> > This is the working group last-call for draft-ietf-emu-eap-tls13.
> Please review the draft, focus on the recent changes and submit your
> comments to the list by May 20, 2021.
>
>
> Section 1 says:
>
>   While this document updates EAP-TLS [RFC5216], it
>   remains backwards compatible with it and existing implementations of
>   EAP-TLS.
>
> Other than the abstract, this is the only reference to EAP-TLS 1.3
> being backwards compatible with older versions of EAP-TLS.  This
> compatibility is simply asserted, with no further explanation given.
>
> Q: What does "backwards compatible" mean?  How is it achieved?
>
> Suggestion: add text explaining how it is backwards compatible.  How
> will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
> update Section 2.1 with text indicating that TLS version negotiation
> is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically
> leverage that capability.
>
>
[Joe]  This text is in PR #71
.



>
> Section 2.1.1 says:
>
>   TLS 1.3 introduced the Post-Handshake KeyUpdate
>   message which is not useful and not expected in EAP-TLS.
>
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.
>
> Suggestion: If there is no use for KeyUpdate messages, then mandate
> that it SHOULD be ignored, or perhaps connections which use KeyUpdate
> MUST be closed without updating the keys.  OpenSSL as APIs to
> determine the status of key updates, so this suggestion is
> implementable.
>
>
[Joe]  I don't see an advantage to having a special case for the KeyUpdate
message.  If the server sends a key update then the peer can just process
it with the rest of the payload it receives.  Since the peer sends no data
it does not matter if it updates the keys or not.   It might be useful to
update this section to say " TLS 1.3 introduced the Post-Handshake
KeyUpdate message which SHOULD NOT be used in EAP-TLS because only one byte
of application data is sent."


>
> Section 2.1.3 says this about the session ticket:
>
>   ... If the EAP-TLS server
>   accepts it, then the security context of the new connection is tied
>   to the original connection and the key derived from the initial
>   handshake is used to bootstrap the cryptographic state instead of a
>   full handshake.
>
> Nit: This the the only reference to "bootstrap the cryptographic
> state" in this document.  This text seems like an unnecessary
> repetition of RFC 8446 Section 2.2.
>
> Suggestion: Perhaps say instead
>
>   ... If the EAP-TLS server
>   accepts it, then the resumed session has been deemed to be
>   authenticated, and securely associated with the prior authentication
>   or resumption.
>
>
[Joe]  This text is in PR #71
.


>
> Section 2.1.4
>
>In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
>fatal error condition.  Failure to send TLS Error alerts means that
>the peer or server would have no way of determining what went wrong.
>EAP-TLS 1.3 strengthen this requirement.
>
> NIT: strengthenS this requirement.
>
>
[Joe] This nit is fixed in the current git-hub draft


> Section 2.1.5 is essentially empty.
>
>  Is there guidance as to when no peer authentication should /
> should not be used?  Is it possible for an EAP peer to present a
> client certificate, but have the EAP server ignore it?  What kind of
> network access should an EAP peer have if it does not use peer
> authentication?
>
>   Perhaps some of the text from Section 5.6 could be added here.
>
> Perhaps suggest that in the normal case, deployments SHOULD use peer
> authentication.  Also that the "no peer authentication" case be
> strictly limited in both time, and network access.
>
> 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.
>
> Also, the Security Considurations section has no discussion of the
> security impact of not authenticating the peer.  As Section 2.1.5 is
> new, it has major impacts on security, and thus needs to be discussed.
>
>
[Joe] I agree that this should be discussed in the security
considerations.   This is discussion of this in section 5.4.


>
> Section 2.1.6 says:
>
>   As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
>   HelloRetryRequest message in response to a ClientHello if the EAP-TLS
>   server f

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[John Mattsson]

Hi Meiling,

In version 15 the group decided to go back more or less to how things worked in 
version 13 where protected TLS application Data 0x00 is send instead of 
close_notify.  This is changed in a lot of places in the draft.

A big change from -13 is that where protected TLS application Data 0x00 is not 
a protected success indication as defined in RFC 3748. That the server only 
sends EAP-success after this follow from it being a protected success 
indication.

When reading through the document to write this answer I saw that there was 
some leftover from the commitment message still in the draft. I made a PR to 
address this.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/69

EAP-success is not encrytpted in any way. It is defined in RFC 3748.

Cheers,
John

From: Emu  on behalf of Meiling Chen 

Date: Saturday, 8 May 2021 at 10:25
To: Joseph Salowey , emu 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

I have noticed that there is one modification in the Figure 1 flow diagram of 
edition 15.
edition 14 has TLS close_notify message, but in edition 15 changed into TLS 
application Data 0x00.
in the section 2.1.1, it says" TLS application data 0x00 is therefore to

   be interpreted as success after the EAP-Request that contains TLS

   application data 0x00.  After the EAP-TLS server has received an

   empty EAP-Response to the EAP-Request containing the TLS application
   data 0x00, the EAP-TLS server sends EAP-Success."
is the data 0x00 that mean not send any more handshake messages?
another question: what's the format of the EAP-success measge, plaintext ot 
ciphertext?

Best Regards,
Meiling

From: Joseph Salowey<mailto:j...@salowey.net>
Date: 2021-05-05 23:33
To: EMU WG<mailto:emu@ietf.org>
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
review the draft, focus on the recent changes and submit your comments to the 
list by May 20, 2021.

Thanks,

Joe

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-15
https://datatracker.ietf.org/doc/html/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-15
___
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

[Meiling Chen]

I have noticed that there is one modification in the Figure 1 flow diagram of 
edition 15.
edition 14 has TLS close_notify message, but in edition 15 changed into TLS 
application Data 0x00.
in the section 2.1.1, it says" TLS application data 0x00 is therefore to
   be interpreted as success after the EAP-Request that contains TLS
   application data 0x00.  After the EAP-TLS server has received an
   empty EAP-Response to the EAP-Request containing the TLS application 
   data 0x00, the EAP-TLS server sends EAP-Success."
is the data 0x00 that mean not send any more handshake messages?
another question: what's the format of the EAP-success measge, plaintext ot 
ciphertext?

Best Regards,
Meiling
 
From: Joseph Salowey
Date: 2021-05-05 23:33
To: EMU WG
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
review the draft, focus on the recent changes and submit your comments to the 
list by May 20, 2021.   

Thanks,

Joe

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-15
https://datatracker.ietf.org/doc/html/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-15
___
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

[Jorge Vergara]

>[Joe] I think the one issue that was raised during TLS review was that using 
>the same label for MSK and EMSK could make it more difficult to separate out 
>the derivations of these keys at the TLS level.  For example, example, perhaps 
>the TLS implementation could restrict access to the MSK and EMSK independently 
>depending upon hte caller.  In practice, it is EAP-TLS that is the caller and 
>the use cases that require the separate derivation of these two keys of these 
>two keys is few to none.  I'll start a short consensus call on this issue.

I reviewed all of the concerns I was able to find in the group archives, and 
the concerns mostly seemed to express that the combined derivation (draft-13) 
was a bit "clumsy" with potential to clean it up a bit, but I didn't find any 
strong objections. Looking forward to more input from the group as to whether 
the draft-13 exporter is livable.

Jorge Vergara

From: Joseph Salowey 
Sent: Friday, May 7, 2021 2:19 PM
To: Jorge Vergara 
Cc: Alan DeKok ; EMU WG 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



On Fri, May 7, 2021 at 1:09 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
>   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
>   Method-Id SHALL be derived from the exporter_secret using the TLS
>   exporter interface [RFC5705] (for TLS 1.3 this is defined in
>   Section 7.5 of [RFC8446]).
>
>   Type-Code  = 0x0D
>   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
>   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
>   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
>   Session-Id = Type-Code || Method-Id
>
> All this is nice, but it might be too late.  I'd check with major 
> implementations which have frozen their code, and are shipping.

The Windows implementation is using draft-13 exporters; it is not possible to 
change at this point unless a critical technical issue that prevents 
functionality or impacts security were to be discovered. I don't think this is 
such an issue. The preference to keep draft-13 exporters was discussed at IETF 
110 and I do not recall any objection. The draft-15 exporter is problematic for 
Windows at this point.

[Joe] I think the one issue that was raised during TLS review was that using 
the same label for MSK and EMSK could make it more difficult to separate out 
the derivations of these keys at the TLS level.  For example, example, perhaps 
the TLS implementation could restrict access to the MSK and EMSK independently 
depending upon hte caller.  In practice, it is EAP-TLS that is the caller and 
the use cases that require the separate derivation of these two keys of these 
two keys is few to none.  I'll start a short consensus call on this issue.

I have fewer opinions on the less-technical areas of the draft. One of my flaws 
as an implementor of several EAP methods is that I can parse the current draft 
and assume enough intent to complete my implementation. I do call out questions 
I have - but I sometimes make assumptions without realizing due to prior 
experience in the area. This may be true of several others in the working group 
as well. Non-implementors don't have the luxury of this experience and I think 
it is extremely difficult to create a secure and robust EAP method 
implementation from scratch. The more guidance toward this goal that can be 
included in the document the better, in my opinion.

[Joe] Thanks, having a more voices chime in on issues can help resolve them 
more quickly and satisfactorily.

Jorge

-Original Message-
From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of Alan 
DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



> On May 5, 2021, at 11:33 AM, Joseph Salowey 
> mailto:j...@salowey.net>> wrote:
>
> This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
> review the draft, focus on the recent changes and submit your comments to the 
> list by May 20, 2021.


Section 1 says:

  While this document updates EAP-TLS [RFC5216], it
  remains backwards compatible with it and existing implementations of
  EAP-TLS.

Other than the abstract, this is the only reference to EAP-TLS 1.3 being 
backwards compatible with older versions of EAP-TLS.  This compatibility is 
simply asserted, with no further explanation given.

Q: What does "backwards compatible" mean?  How is it achieved?

Suggestion: add text explaining how it is backwards compatible.  How will 
EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section 2.1 
with text indicating that TLS version negotiation is handled by the TLS layer, 
and thus outside of the scope

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Alan DeKok]

On May 7, 2021, at 5:18 PM, Joseph Salowey  wrote:
> [Joe] I think the one issue that was raised during TLS review was that using 
> the same label for MSK and EMSK could make it more difficult to separate out 
> the derivations of these keys at the TLS level.  For example, example, 
> perhaps the TLS implementation could restrict access to the MSK and EMSK 
> independently depending upon hte caller.

  I'll have to think about that a little more before I understand the 
underlying objection.

  From what I can see, MSK and EMSK are specific to EAP-TLS.  They are derived 
in the EAP-TLS application, by passing EAP-TLS parameters to TLS key exporters.

  So the TLS layer has no concept of what MSK or EMSK are.  As a result, the 
TLS layer should have minimal input into what those keys are, or how they are 
derived.

  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

[Joseph Salowey]

On Fri, May 7, 2021 at 1:09 PM Jorge Vergara  wrote:

> >   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
> >   Method-Id SHALL be derived from the exporter_secret using the TLS
> >   exporter interface [RFC5705] (for TLS 1.3 this is defined in
> >   Section 7.5 of [RFC8446]).
> >
> >   Type-Code  = 0x0D
> >   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
> >   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
> >   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
> >   Session-Id = Type-Code || Method-Id
> >
> > All this is nice, but it might be too late.  I'd check with major
> implementations which have frozen their code, and are shipping.
>
> The Windows implementation is using draft-13 exporters; it is not possible
> to change at this point unless a critical technical issue that prevents
> functionality or impacts security were to be discovered. I don't think this
> is such an issue. The preference to keep draft-13 exporters was discussed
> at IETF 110 and I do not recall any objection. The draft-15 exporter is
> problematic for Windows at this point.
>
>
[Joe] I think the one issue that was raised during TLS review was that
using the same label for MSK and EMSK could make it more difficult to
separate out the derivations of these keys at the TLS level.  For example,
example, perhaps the TLS implementation could restrict access to the MSK
and EMSK independently depending upon hte caller.  In practice, it is
EAP-TLS that is the caller and the use cases that require the separate
derivation of these two keys of these two keys is few to none.  I'll start
a short consensus call on this issue.


> I have fewer opinions on the less-technical areas of the draft. One of my
> flaws as an implementor of several EAP methods is that I can parse the
> current draft and assume enough intent to complete my implementation. I do
> call out questions I have - but I sometimes make assumptions without
> realizing due to prior experience in the area. This may be true of several
> others in the working group as well. Non-implementors don't have the luxury
> of this experience and I think it is extremely difficult to create a secure
> and robust EAP method implementation from scratch. The more guidance toward
> this goal that can be included in the document the better, in my opinion.
>
>
[Joe] Thanks, having a more voices chime in on issues can help resolve them
more quickly and satisfactorily.


> Jorge
>
> -----Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Thursday, May 6, 2021 12:12 PM
> To: Joseph Salowey 
> Cc: EMU WG 
> Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
>
>
>
> > On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> >
> > This is the working group last-call for draft-ietf-emu-eap-tls13.
> Please review the draft, focus on the recent changes and submit your
> comments to the list by May 20, 2021.
>
>
> Section 1 says:
>
>   While this document updates EAP-TLS [RFC5216], it
>   remains backwards compatible with it and existing implementations of
>   EAP-TLS.
>
> Other than the abstract, this is the only reference to EAP-TLS 1.3 being
> backwards compatible with older versions of EAP-TLS.  This compatibility is
> simply asserted, with no further explanation given.
>
> Q: What does "backwards compatible" mean?  How is it achieved?
>
> Suggestion: add text explaining how it is backwards compatible.  How will
> EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section
> 2.1 with text indicating that TLS version negotiation is handled by the TLS
> layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically leverage
> that capability.
>
>
> Section 2.1.1 says:
>
>   TLS 1.3 introduced the Post-Handshake KeyUpdate
>   message which is not useful and not expected in EAP-TLS.
>
> Q: What does it mean that the message is "not expected"?  This seems like
> a source of implementation-defined behavior, which experience shows has
> been a source of interoperability and security issues.
>
> Suggestion: If there is no use for KeyUpdate messages, then mandate that
> it SHOULD be ignored, or perhaps connections which use KeyUpdate MUST be
> closed without updating the keys.  OpenSSL as APIs to determine the status
> of key updates, so this suggestion is implementable.
>
>
> Section 2.1.3 says this about the session ticket:
>
>   ... If the EAP-TLS server
>   accepts it, then the security context 

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Alan DeKok]

On May 7, 2021, at 4:09 PM, Jorge Vergara  wrote:
> The Windows implementation is using draft-13 exporters; it is not possible to 
> change at this point unless a critical technical issue that prevents 
> functionality or impacts security were to be discovered. I don't think this 
> is such an issue. The preference to keep draft-13 exporters was discussed at 
> IETF 110 and I do not recall any objection. The draft-15 exporter is 
> problematic for Windows at this point.

  The interop report involved Microsoft, FreeRADIUS, and hostap.  All have 
implemented the -13 exporters, and the 0x00 Commitment message.  
Interoperablity has been demonstrated to the satisfaction of all participants.

  Pretty much everyone else with supplicant and/or RADIUS server 
implementations is out of the loop.  They're either unaware of this work, or 
have no opinions on it.

  From the Open Source side, it's easy to change code.  But I will not ship a 
product which fails to interoperate with the dominant supplicant platform.

  I see no major security issues with the -13 exporters.  It's "nicer" to use 
separate labels, but it's not critically important for the security of the 
protocol.

> I have fewer opinions on the less-technical areas of the draft. One of my 
> flaws as an implementor of several EAP methods is that I can parse the 
> current draft and assume enough intent to complete my implementation. I do 
> call out questions I have - but I sometimes make assumptions without 
> realizing due to prior experience in the area. This may be true of several 
> others in the working group as well. Non-implementors don't have the luxury 
> of this experience and I think it is extremely difficult to create a secure 
> and robust EAP method implementation from scratch. The more guidance toward 
> this goal that can be included in the document the better, in my opinion.

  I agree.

  I have expressed strong opinions that the document gives insufficient 
guidance to implementors.  For me, "rough consensus and running code" means I 
should be able to say the following, and be taken seriously:

  "Hi, as someone with running code, I believe that it is critical for the 
specification to say X, in order to address implementation and interoperability 
issues".

  It's surprising when the response to such a comment is "No".

  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

[Jorge Vergara]

>   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
>   Method-Id SHALL be derived from the exporter_secret using the TLS
>   exporter interface [RFC5705] (for TLS 1.3 this is defined in
>   Section 7.5 of [RFC8446]).
>
>   Type-Code  = 0x0D
>   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
>   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
>   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
>   Session-Id = Type-Code || Method-Id
>
> All this is nice, but it might be too late.  I'd check with major 
> implementations which have frozen their code, and are shipping.

The Windows implementation is using draft-13 exporters; it is not possible to 
change at this point unless a critical technical issue that prevents 
functionality or impacts security were to be discovered. I don't think this is 
such an issue. The preference to keep draft-13 exporters was discussed at IETF 
110 and I do not recall any objection. The draft-15 exporter is problematic for 
Windows at this point.

I have fewer opinions on the less-technical areas of the draft. One of my flaws 
as an implementor of several EAP methods is that I can parse the current draft 
and assume enough intent to complete my implementation. I do call out questions 
I have - but I sometimes make assumptions without realizing due to prior 
experience in the area. This may be true of several others in the working group 
as well. Non-implementors don't have the luxury of this experience and I think 
it is extremely difficult to create a secure and robust EAP method 
implementation from scratch. The more guidance toward this goal that can be 
included in the document the better, in my opinion.

Jorge

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey 
Cc: EMU WG 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



> On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> 
> This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
> review the draft, focus on the recent changes and submit your comments to the 
> list by May 20, 2021.   


Section 1 says:

  While this document updates EAP-TLS [RFC5216], it
  remains backwards compatible with it and existing implementations of
  EAP-TLS. 

Other than the abstract, this is the only reference to EAP-TLS 1.3 being 
backwards compatible with older versions of EAP-TLS.  This compatibility is 
simply asserted, with no further explanation given.

Q: What does "backwards compatible" mean?  How is it achieved?

Suggestion: add text explaining how it is backwards compatible.  How will 
EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section 2.1 
with text indicating that TLS version negotiation is handled by the TLS layer, 
and thus outside of the scope of EAP-TLS.
Therefore so long as the underlying TLS implementation correctly implements TLS 
version negotiation, EAP-TLS will automatically leverage that capability.


Section 2.1.1 says:

  TLS 1.3 introduced the Post-Handshake KeyUpdate
  message which is not useful and not expected in EAP-TLS. 

Q: What does it mean that the message is "not expected"?  This seems like a 
source of implementation-defined behavior, which experience shows has been a 
source of interoperability and security issues.

Suggestion: If there is no use for KeyUpdate messages, then mandate that it 
SHOULD be ignored, or perhaps connections which use KeyUpdate MUST be closed 
without updating the keys.  OpenSSL as APIs to determine the status of key 
updates, so this suggestion is implementable.


Section 2.1.3 says this about the session ticket:

  ... If the EAP-TLS server
  accepts it, then the security context of the new connection is tied
  to the original connection and the key derived from the initial
  handshake is used to bootstrap the cryptographic state instead of a
  full handshake. 

Nit: This the the only reference to "bootstrap the cryptographic state" in this 
document.  This text seems like an unnecessary repetition of RFC 8446 Section 
2.2.

Suggestion: Perhaps say instead

  ... If the EAP-TLS server
  accepts it, then the resumed session has been deemed to be
  authenticated, and securely associated with the prior authentication
  or resumption.


Section 2.1.4

   In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
   fatal error condition.  Failure to send TLS Error alerts means that
   the peer or server would have no way of determining what went wrong.
   EAP-TLS 1.3 strengthen this requirement. 

NIT: strengthenS this requirement.

Section 2.1.5 is essentially empty.

 Is there guidance as to when no peer authentication should / should not be 
used?  Is it possible for an EAP peer to present a client certificate, but have 
the EAP server ignore i

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Alan DeKok]

> On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> 
> This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
> review the draft, focus on the recent changes and submit your comments to the 
> list by May 20, 2021.   


Section 1 says:

  While this document updates EAP-TLS [RFC5216], it
  remains backwards compatible with it and existing implementations of
  EAP-TLS. 

Other than the abstract, this is the only reference to EAP-TLS 1.3
being backwards compatible with older versions of EAP-TLS.  This
compatibility is simply asserted, with no further explanation given.

Q: What does "backwards compatible" mean?  How is it achieved?

Suggestion: add text explaining how it is backwards compatible.  How
will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
update Section 2.1 with text indicating that TLS version negotiation
is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
Therefore so long as the underlying TLS implementation correctly
implements TLS version negotiation, EAP-TLS will automatically
leverage that capability.


Section 2.1.1 says:

  TLS 1.3 introduced the Post-Handshake KeyUpdate
  message which is not useful and not expected in EAP-TLS. 

Q: What does it mean that the message is "not expected"?  This seems
like a source of implementation-defined behavior, which experience
shows has been a source of interoperability and security issues.

Suggestion: If there is no use for KeyUpdate messages, then mandate
that it SHOULD be ignored, or perhaps connections which use KeyUpdate
MUST be closed without updating the keys.  OpenSSL as APIs to
determine the status of key updates, so this suggestion is
implementable.


Section 2.1.3 says this about the session ticket:

  ... If the EAP-TLS server
  accepts it, then the security context of the new connection is tied
  to the original connection and the key derived from the initial
  handshake is used to bootstrap the cryptographic state instead of a
  full handshake. 

Nit: This the the only reference to "bootstrap the cryptographic
state" in this document.  This text seems like an unnecessary
repetition of RFC 8446 Section 2.2.

Suggestion: Perhaps say instead

  ... If the EAP-TLS server
  accepts it, then the resumed session has been deemed to be
  authenticated, and securely associated with the prior authentication
  or resumption.


Section 2.1.4

   In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
   fatal error condition.  Failure to send TLS Error alerts means that
   the peer or server would have no way of determining what went wrong.
   EAP-TLS 1.3 strengthen this requirement. 

NIT: strengthenS this requirement.

Section 2.1.5 is essentially empty.

 Is there guidance as to when no peer authentication should /
should not be used?  Is it possible for an EAP peer to present a
client certificate, but have the EAP server ignore it?  What kind of network 
access should an EAP peer have if it does not use peer authentication?

  Perhaps some of the text from Section 5.6 could be added here.

Perhaps suggest that in the normal case, deployments SHOULD use peer
authentication.  Also that the "no peer authentication" case be
strictly limited in both time, and network access.

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.

Also, the Security Considurations section has no discussion of the
security impact of not authenticating the peer.  As Section 2.1.5 is
new, it has major impacts on security, and thus needs to be discussed.


Section 2.1.6 says:

  As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
  HelloRetryRequest message in response to a ClientHello if the EAP-TLS
  server finds an acceptable set of parameters but the initial
  ClientHello does not contain all the needed information to continue
  the handshake.

It's not clear why this section is necessary.  The text here appears
to be discussing internals of TLS layer negotiation, which are
invisible to EAP-TLS.  That is, this packet flow has no effect on the
EAP-TLS state machine, other than a different number of packets are
exchanged than with other packet flows.

Question: Is it that "EAP-TLS server" does not have sufficient
information to continue the handshake, or is it "the TLS layer" ?

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?


Section 2.1.9 says:

  Some EAP implementations and access networks may limit the number of
  EAP packet exchanges that can be handled.

This is under-stating the issue rather severely.  We know with
absolute certainty that most (if not all) EAP implementations and
access networks limit the number of EAP packet exchanges. 

[Emu] WG Last Call for Using EAP-TLS with TLS 1.3

[Joseph Salowey]

This is the working group last-call for draft-ietf-emu-eap-tls13.  Please
review the draft, focus on the recent changes and submit your comments to
the list by May 20, 2021.

Thanks,

Joe

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-15
https://datatracker.ietf.org/doc/html/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-15
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu