Re: [Emu] EAP-TLS 1.3 Section 2.2 text

[Oleg Pekar]

To section: 2.2.  Identity Verification

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

-- comment:
What is meant by "EAP server for the network"?

2)
EAP peer implementations SHOULD allow users to configuring a unique trust
root (CA certificate)

-- comment:
Should say "a unique trusted root" in conformance with the other occurrence.

3)
To facilitate SAN matching, EAP Server
   certificates can include the same name in the list of SANs for each
   certificate that represents the EAP-TLS servers.

-- comment:
Could you please clarify the idea of adding the same name to SAN of
multiple certificates, since some EAP-TLS server certificates are just
generic certificates and their SAN DNS and IP fields may contain the unique
value per server instance.

Regards,
Oleg

On Mon, May 17, 2021 at 7:06 PM Russ Housley  wrote:

> Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative
> name extension, which as an ASN.1 definition for SubjectAltName.  So,
> please do not refer to subjectAlternativeName.
>
> Russ
>
>
> On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
>
> I proposed a PR#72
>  based on
> this suggestion. The resulting text for the section is below.  Please
> review to see if it is OK.
>
> Thanks,
>
> Joe
>
> 2.2.  Identity Verification
>
>This section updates Section 2.2 of [RFC5216].
>
>The EAP peer identity provided in the EAP-Response/Identity is not
>authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
>used for accounting purposes or to give authorization.  The
>authenticator and the EAP-TLS server MAY examine the identity
>presented in EAP-Response/Identity for purposes such as routing and
>EAP method selection.  EAP-TLS servers MAY reject conversations if
>the identity does not match their policy.  Note that this also
>applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
>
>The EAP server identity in the TLS server certificate is typically a
>fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>allow users to configure a unique trust root (CA certificate) and a
>server name to authenticate the server certificate and match the
>subjectAlternativeName (SAN) extension in the server certificate with
>the configured server name.  EAP-TLS deployments will often use more
>than one EAP server.  In this case each EAP server may have a
>different certificate.  To facilitate SAN matching, EAP Server
>certificates can include the same name in the list of SANs for each
>certificate that represents the EAP-TLS servers.  EAP-TLS peers
>SHOULD allow for the configuration of multiple EAP server names since
>deployments may choose to use multiple EAP servers each with their
>own certificate.  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.  If name matching is not used with
>a public root CA, then effectively any server can obtain a
>certificate which will be trusted for EAP authentication by the Peer.
>
>
>The process of configuring a root CA certificate and a server name is
>non-trivial and therefore automated methods of provisioning are
>RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>a Configuration Assistant Tool (CAT) to automate the configuration
>process.  In the absence of a trusted root CA certificate (user
>configured or system-wide), EAP peers MAY implement a trust on first
>use (TOFU) mechanism where the peer trusts and stores the server
>certificate during the first connection attempt.  The EAP peer
>ensures that the server presents the same stored certificate on
>subsequent interactions.  Use of a TOFU mechanism does not allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
>
>
> On Mon, May 10, 2021 at 5:11 AM Alan DeKok 
> wrote:
>
>> On May 9, 2021, at 9:16 PM, Joseph Salowey  wrote:
>> > [Joe]  This is a good question.  There are multiple ways this could be
>> addressed.  All servers should have one of their list of SANs that matches
>> the name used for EAP servers.  Another option is for supplicants to allow
>> for the configuration of multiple certificates or allow for a wild card
>> match.
>>
>>   FWIW, wpa_supplicant has a list of allowed host names for SAN.  I don't
>> think it allows wildcards.
>>
>> >   How about this text addition:
>> >
>> > "EAP-TLS deployments will often use more than one EAP server.  In this
>> case each EAP server may have a different certificate.  To facilitate the
>> SAN 

[Emu] EAP-TLS key derivation and interoperability based on draft 13

[Heikki Vatiainen]

I'd like to express my support for draft version 13 key derivation.

I just recently joined the list so I'm unable to respond directly to Joe's
message on May 9th.

My main concern from the viewpoint of RADIUS / EAP server maintainer is the
potential bifurcation of implementations and the upcoming RFC. Our server
implementation interoperates with draft version 13 clients, and because it
now seems that Microsoft will ship based a client on draft 13, this will in
effect fixate our server to support draft 13.

Some list members may remember a bit similar case happening with PEAP.
PEAPv1 drafts used 'client PEAP encryption' label with key derivation.
However, a number of clients continued to use 'client EAP encryption'. When
this happened, the only option on the server side that was available was to
have a configuration flag that forced PEAPv1 label to either or. Debugging
this was really hard because even if the authentication completed
successfully, for example in case of Wi-Fi, the client and WLAN AP
encryption keys did not match. All logs looked fine but the radio layer
encryption did not work causing eventual timeouts and debugging nightmare.
Luckily PEAPv1 usage did not become very wide spread.

Based on the above, I think it's extremely important to make sure the
implementations and the specifications match.

The label problem seen with PEAPv1 would be the same with EAP-TLS/TLSv1.3
too if we let it happen. Fortunately it seems that there are no major
reasons to proceed with draft version 13 key derivation. I'm also happy to
support TLS application data 0x00 for messaging. I noticed there was recent
discussion about this with relation to other options.

Radiator first implemented EAP-TLS in 2002 (19 years ago) and is where
RadSec (RFC 6614 - TLS Encryption for RADIUS) first originated from. We
currently interoperate with a number of clients, Android, Apple, Microsoft
and others. Being a server software vendor, we have also been fortunate to
gather experience working with different client and server implementations.
Radiator is used by individual organisations, roaming federations, such as
eduroam, for proxying, authentication and other tasks. I won't go further
but I thought it might be useful to say a little about where we are coming
from.

I'll take a further look at the current draft and past discussion next but
I thought I'd start by replying to Joe's call before the May 20th deadline.

--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

[Russ Housley]

Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative name 
extension, which as an ASN.1 definition for SubjectAltName.  So, please do not 
refer to subjectAlternativeName.

Russ


> On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
> 
> I proposed a PR#72 
>  based on this 
> suggestion. The resulting text for the section is below.  Please review to 
> see if it is OK.
> 
> Thanks,
> 
> Joe
> 
> 2.2.  Identity Verification
> 
>This section updates Section 2.2 of [RFC5216].
> 
>The EAP peer identity provided in the EAP-Response/Identity is not
>authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
>used for accounting purposes or to give authorization.  The
>authenticator and the EAP-TLS server MAY examine the identity
>presented in EAP-Response/Identity for purposes such as routing and
>EAP method selection.  EAP-TLS servers MAY reject conversations if
>the identity does not match their policy.  Note that this also
>applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
> 
>The EAP server identity in the TLS server certificate is typically a
>fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>allow users to configure a unique trust root (CA certificate) and a
>server name to authenticate the server certificate and match the
>subjectAlternativeName (SAN) extension in the server certificate with
>the configured server name.  EAP-TLS deployments will often use more
>than one EAP server.  In this case each EAP server may have a
>different certificate.  To facilitate SAN matching, EAP Server
>certificates can include the same name in the list of SANs for each
>certificate that represents the EAP-TLS servers.  EAP-TLS peers
>SHOULD allow for the configuration of multiple EAP server names since
>deployments may choose to use multiple EAP servers each with their
>own certificate.  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.  If name matching is not used with
>a public root CA, then effectively any server can obtain a
>certificate which will be trusted for EAP authentication by the Peer.
>
>The process of configuring a root CA certificate and a server name is
>non-trivial and therefore automated methods of provisioning are
>RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>a Configuration Assistant Tool (CAT) to automate the configuration
>process.  In the absence of a trusted root CA certificate (user
>configured or system-wide), EAP peers MAY implement a trust on first
>use (TOFU) mechanism where the peer trusts and stores the server
>certificate during the first connection attempt.  The EAP peer
>ensures that the server presents the same stored certificate on
>subsequent interactions.  Use of a TOFU mechanism does not allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
> 
> On Mon, May 10, 2021 at 5:11 AM Alan DeKok  > wrote:
> On May 9, 2021, at 9:16 PM, Joseph Salowey  > wrote:
> > [Joe]  This is a good question.  There are multiple ways this could be 
> > addressed.  All servers should have one of their list of SANs that matches 
> > the name used for EAP servers.  Another option is for supplicants to allow 
> > for the configuration of multiple certificates or allow for a wild card 
> > match.
> 
>   FWIW, wpa_supplicant has a list of allowed host names for SAN.  I don't 
> think it allows wildcards.
> 
> >   How about this text addition:
> > 
> > "EAP-TLS deployments will often use more than one EAP server.  In this case 
> > each EAP server may have a different certificate.  To facilitate the SAN 
> > matching, EAP Server certificates can include the same name in the list of 
> > SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS 
> > peers SHOULD allow for the configuration of multiple EAP server names since 
> > deployments may choose to use multiple EAP servers each with their own 
> > certificate." 
> 
>   That's good.
> 
> > [Joe] Is your comment about HA and the TOFU mechanism?  I'm not really sure 
> > how the TOFU mechanism is supposed to work and be secure.  Perhaps we 
> > should remove the TOFU mechanism text or state that it does not work well 
> > in all HA configurations (where different servers use different 
> > certificates)
> 
>   Perhaps just state that it does not work well in HA configurations.
> 
>   I don't think TOFU can be secure here.
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list

Re: [Emu] EAP-TLS 1.3 - few more comments

[Oleg Pekar]

Thanks Joe, one comment regarding item #16 is inline below.

On Sun, May 16, 2021 at 9:52 PM Joseph Salowey  wrote:

> Hi Oleg,
>
> thanks for the review, comments below:
>
> On Sun, May 16, 2021 at 1:55 AM Oleg Pekar 
> wrote:
>
>> Hi, few more comments on the draft #15
>> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/:
>>
>> 1)
>>
>> 2.1.1.  Authentication
>>
>> The full handshake in EAP-TLS with TLS 1.3 always
>>provide forward secrecy by exchange of ephemeral "key_share"
>>extensions in the ClientHello and ServerHello (e.g. containing
>>ephemeral ECDHE public keys).
>>
>> —- comment:
>> should say “provides”
>>
>> —
>>
>> 2)
>>
>> 2.1.1.  Authentication
>>
>> 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.
>>
>> -- comment:
>> the phrase “empty EAP-Response” may be confusing. EAP-TLS RFC [RFC 5216]
>> calls such messages as "EAP-Response packet of EAP-Type=EAP-TLS and no
>> data" (Section 2.1.3. Termination, 2.1.5.  Fragmentation). Suggest continue
>> using the old RFC terminology since Figure 1 preserves the same messages
>> names.
>>
>> —
>>
>> 3)
>>
>> 2.1.1.  Authentication
>>
>> Figure 1: EAP-TLS mutual authentication
>>
>> -- comment:
>> "TLS Application Data 0x00)" lacks opening round bracket
>>
>> —
>>
>> 4)
>>
>> 2.1.2.  Ticket Establishment
>>
>> Figure 2: EAP-TLS ticket establishment
>>
>> -- comment:
>> "TLS Application Data 0x00)" lacks opening round bracket
>>
>> —
>>
>> 5)
>>
>> 2.1.3.  Resumption
>>
>> Figure 3: EAP-TLS resumption
>>
>> -- comment:
>> "TLS Application Data 0x00)" lacks opening round bracket
>>
>> —
>>
>>
> [Joe] Authors, please address the above nits.
>
>
>> 6)
>>
>> 2.1.3.  Resumption
>>
>> Providing a
>>"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
>>is also important in order to limit the impact of a key compromise.
>>When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
>>that key leakage does not compromise any earlier connections.  It is
>>RECOMMMENDED to use "psk_dhe_ke" for resumption.
>>
>> -- comment:
>> The recommendation may be interpreted ambiguously. Is it recommended to
>> TLS server to reject EAP-TLS session resumption from EAP-TLS peer and
>> fallback to full handshake when there's no "psk_dhe_ke" extension?
>>
>
> [Joe] SHOULD and RECOMMENDED are a bit ambiguous.  Perhaps this can be
> replaced by something better:
>
> "psk_dh_ke" MUST be used for resumption unless the deployment has a local
> requirement to allow configuration of other mechanisms."
>
>
>>
>>
>> —
>>
>> 7)
>>
>> 2.1.4.  Termination
>>
>> 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.  Whenever an implementation
>>encounters a fatal error condition, it MUST send an appropriate TLS
>>Error alert.
>>
>> -- comment:
>> It there a way to enforce sending TLS Error alert? Since the conversation
>> is probably failed anyway after the case that requires sending TLS Error
>> alert - there is no real feasible enforcement to be specified. I remember a
>> lot of suffering due to EAP-TLS peers just broke connection with no
>> indication of what was wrong, so admins cannot really reveal the cure for
>> the failed authentication.
>>
>>
> [Joe] This section does say that TLS error alerts MUST be sent.  Are you
> looking for something else?
>
>
>> —
>>
>> 8)
>>
>> 2.1.4.  Termination
>>
>> Figure 6 shows an example message flow where the EAP-TLS server
>>authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
>>fails to authenticate to the EAP-TLS server and sends a TLS Error
>>alert.
>>
>> -- comment:
>> "the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a
>> TLS Error" - there's an impression from this text that EAP-TLS peers sends
>> a TLS error. However it is EAP-TLS server that does it. Should be
>> clarified. Example of suggestion:
>>
>> Figure 6 shows an example message flow where the EAP-TLS server
>>authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
>>fails to authenticate to the EAP-TLS server and the server sends a TLS
>> Error
>>alert.
>>
>>
> [Joe] Authors please reword this text to be less ambiguous.
>
>
>> —
>>
>> 9)
>>
>> 2.1.5.  No Peer Authentication
>>
>> -- comment:
>> Can "TLS CertificateRequest" message still be sent by EAP-TLS server?
>> Should EAP-TLS peer silently discard it or reject the connection in case it
>> is sent but EAP-TLS peer doesn't own a credentials to authenticate?
>>
>>
> [Joe] I think this is covered by TLS 

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] EAP-TLS 1.3 Section 2.2 text

[Eliot Lear]

Let this be the biggest argument on this list ;-)

> On 17 May 2021, at 14:44, Alan DeKok  wrote:
> 
> 
>  This is just a personal preference, but "MUST NOT" is clearer to me than 
> SHALL NOT.  It's also more used, IIRC.



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

[Alan DeKok]

On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
> I proposed a PR#72 based on this suggestion. The resulting text for the 
> section is below.  Please review to see if it is OK.

  It looks good, subject to minor comments.

>The EAP peer identity provided in the EAP-Response/Identity is not
>authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be

  This is just a personal preference, but "MUST NOT" is clearer to me than 
SHALL NOT.  It's also more used, IIRC.

>The EAP server identity in the TLS server certificate is typically a
>fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>allow users to configure a unique trust root (CA certificate) and a
>server name to authenticate the server certificate and match the

  The later text discusses multiple names, so perhaps instead

... and one or more server names ...

  Alan DeKok.

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