Windows 7, wired 802.1x, native EAP-TLS w/o AD, NPS

[Stefan Winter]

Hi,

>>> The cert is generated by freeradius' makefile, however, the EAP session
>>> stalls and FR complains:
>>> | WARNING:
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> | WARNING: !! EAP session for state 0xe0880a2ce3de07a8 did not finish!
>>> | WARNING: !! Please read
>>> http://wiki.freeradius.org/guide/Certificate_Compatibility
>>> | WARNING:
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> which seems a bit circular, but I'll try to resolve this myself before
>>> asking for further assistence.
>> Progress!  It turns out that 2048-bit certificates (as generated by FR's
>> Makefile) cause the EAP session to stall, while 1024 bit certs do work!

You tried both client certs with the same server cert, issued by the
same server-CA?

Because this error message /often/ comes from the client seeing an
unexpected server certificate, which it doesn't trust and then walks
away silently.

If you can exclude server trust issues, then yes, this looks a lot like
an MTU problem.

>> So that might indeed be an MTU issue.  It's mildly surprising, though,
>> because the FR certs are supposedly known to work.

They do: FreeRADIUS can't help it if your network has MTU problems.

> Couple of things to note:
> 
> There are two MTUs to consider - the IP MTU between the NAS and radius
> server, and the layer2 MTU between the NAS and the supplicant.
> 
> The EAP/TLS code will segment the EAP/TLS (or TLS-based like PEAP/TTLS)
> data into chunks of len == Framed-MTU (from the Access-Accept) or if
> that's absent, the "fragment_size" option from the tls{} block of the
> EAP method.
> 
> So if the Access-Accept contains Framed-MTU=1024 you'll get an
> Access-Accept that's a few hundred bytes larger (framing plus the other
> attributes) which should then be a 1024-byte EAP frame at layer2.
> 
> It would be interesting to know if you're getting a Framed-MTU from the
> NAS, and what size radius replies you are seeing going from FR to the NAS.

I don't think this particular explanation is very helpful. Framed-MTU
and fragment_size only helps in situations where the /server/ has a
large chunk to send and needs to decide how to chop it up.

If the conversation breaks as the /client/ certificate gets bigger, none
of those two is going to help.

Supplicants have their own logic for creating fragments. They know which
link they are attached to, and what the MTU on that link is. So the
layer2 MTU is not a problem; they can't possibly go above that. We can
safely assume that this MTU is 1500 or higher on any modern network.

If the client certificate is ~ 1500 or more bytes, the EAP payload needs
to be fragmented. The decision on size is - as per my observations - the
following:

- wpa_supplicant (and by consequence MacOS, iOS, Android, Linux) has a
configurable parameter which defaults to something way below 1500.
- Windows fills the MTU to the max.

So, when you have a Windows supplicant, be prepared that there's a full
1500 byte EAP payload coming to your NAS. The NAS then wraps this inside
a RADIUS packet, which adds size, resulting in a UDP datagram that is
deterministic >1500 bytes. Which in turn means that UDP fragmentation
*will* occur, and the network *must* be prepared to safely deliver the
multiple fragments to the RADIUS server destination.

For eduroam, we are requiring UDP fragmentation support for many years,
for this exact reason (and also because it also helps server-side for
admins setting a high MTU in that direction).

So, fix your network: let UDP fragments pass to the RADIUS server.
Otherwise, your EAP-TLS deployment is going to get stuck. Or at least,
fragments of it ;-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170412/46cfcc1d/attachment-0001.sig>