Hi,
Running a packet capture of an EAP TTLS session against FR cvs head, noticed EAP Notifcation packets are being sent. The type-data appears to match that of the Reply-Message. Is this a feature of rlm_eap that I missed before, or is the NAS being clever about it's interpretation of the Access-Accept packet, and encapsulating the Reply-Message attribute in an EAP-Request Notification packet ?
Didn't we have a similar discussion on this list before, about RFC3579's text in chapter 2.6.5? IIRC, the outcome was that a Access-Accept packet which contains an EAP-Message attribute MUST NOT contain a Reply-Message? And since EAP conversations end with an Access-Accept that always contains an EAP-Message with EAP-Success in it, no Reply-Message should be sent at all? Plus, RFC3579 contains lots of text in that chapter that explains why it is a bad idea to a) send a Reply-Message anyways and b) why a NAS should silently discard this attribute if present, rather than try and translate it to a Notification. So, I agree with Josh that it must be something very NAS-specific, but it's highly dubious that it's a good thing. Then again, if RFC3579 would be updated some time soon so that the behaviour is then standardised and not any more vendor-voodoo (keying material stuff is under review anyways by the HOKEY wg), and if the drawbacks mentioned in there could be solved cleanly, *then* this behaviour could become a good one. A very good one even, for those debugging purposes. Like, concern [1] in RFC3579 section 2.6.5 could be addressed by: the NAS then MUST filter out the EAP-Response/Notification packet and not forward it to the RADIUS server and treat this EAP conversation as ended. concern [2] could be addressed with: since the NAS knows all identifiers in use for current EAP conversations, it can choose one that is currently not in use. Then again, RFC3748 (EAP) states: 5.2. Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method. , the important part being *prior to completion*. So the only message flow that makes sense in this context is (supplicant) (NAS) (RADIUS-Server) ... EAP ... <------------------ Access-Accept with EAP-Message and Reply-Message <--------------- EAP-Req/Notification (containing Reply-M) ---------------> EAP-Resp/Notification --- NAS discards EAP-Resp, no forward to Server --- <--------------- EAP-Success with content of EAP-Message Is that what you're seeing? In that case, quite cool, but that should be somewhat explicitly documented in an update of RFC3579 because it is not exactly trivial. I wonder though why FR permits sending a Reply-Message when an EAP-Message is present. I used to think it forbids that for RFC-compliance reasons. Greetings, Stefan
Either way it's pretty cool, and the message gets logged in /var/log/system.log (On Mac OS X) which has the potential to be useful for debugging...
Thanks, Arran
-- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473