On Tue, 10 Jan 2023 at 19:26, Alan DeKok <al...@deployingradius.com> wrote:
> On Jan 9, 2023, at 5:17 PM, Heikki Vatiainen <h...@radiatorsoftware.com>
> wrote:
> Is it known how widely Unauthenticated mode is used? Can this be left as
> it is for this round of TEAP update?
>
> Implementors please speak up. :)
>
> I think it can be left as-is for this round of TEAP updates.
> Realistically speaking, if the client verifies the server identity, then
> the connection is secure. And any security issues with MS-CHAP become less
> relevant.
>
> i.e. MS-CHAP is insecure against offline dictionary attacks, for
> attackers who can view the MS-CHAP exchange.
>
With *Server Un*authenticated mode a passive attacker can't view the
exchange, but MITM is possible. EAP-FAST allowed EAP-FAST-MSCHAPv2 with
this mode but since then requirements seem to have become stricter.
> If we're running MS-CHAP inside of TLS, then only the client and server
> can observe the MS-CHAP exchange.
>
> If the client verifies the server identity (certificate. etc), then this
> prevents MITM attacks.
>
With Server Unauthenticated Provisioning Mode client does not verify a
certificate and MITM is possible. With an anonymous ciphersuite a
certificate is not required in a Server Hello message. Here's an EAP-FAST
example where the client ( eapol_test from hostapd) has no PAC and it's
configured with anonymous provisioning allowed. Client Hello is not shown,
but it only contains two ciphersuites: TLS_DH_anon_WITH_AES_128_CBC_SHA and
0x00ff (RFC 5746 TLS Renegotiation Extension). EAP-FAST server then sends
this as response to finish its part of TLS handshake. No certificate is
present in Server Hello.
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 89
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 85
Version: TLS 1.2 (0x0303)
Random:
04e834170801843585c851e4fc9a385b9e685e15117e5559820535d1ce9ab0c1
Session ID Length: 32
Session ID:
04e71ab3f6a879a94c0506158fa45b34f2d91b0fa14a79b59a8c074be8d94f89
Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA (0x0034)
Compression Method: null (0)
Extensions Length: 13
Extension: renegotiation_info (len=1)
Extension: encrypt_then_mac (len=0)
Extension: extended_master_secret (len=0)
[JA3S Fullstring: 771,52,65281-22-23]
[JA3S: ecbb9d4a0a2c120e04934d821ba6cb58]
TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 523
Handshake Protocol: Server Key Exchange
Handshake Type: Server Key Exchange (12)
Length: 519
Diffie-Hellman Server Params
TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 4
Handshake Protocol: Server Hello Done
Handshake Type: Server Hello Done (14)
Length: 0
EAP-FAST dynamic provisioning RFC discusses Server-Unauthenticated
Provisioning Mode in detail:
https://datatracker.ietf.org/doc/html/rfc5422#section-6.1.2
TEAP RFC has much less text about Server Unauthenticated mode. I'd say this
gives even more reason to be clear about why EAP-FAST-MSCHAPv2 is no longer
allowed by TEAP with this mode.
The server presumably already knows the password, so it gains no
> information by observing the MS-CHAP exchange.
>
> Any client which knows the password gains no information by observing
> the MS-CHAP exchange.
>
> Attackers can only try MS-CHAP with random guess, and get rejected.
> They can't do anything other than online guesses.
>
> Does that sound correct?
>
For server authenticated operation yes, but with sessions that use
anonymous ciphersuite there's the MITM problem.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
