EAP Notification

[Stefan Winter]

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 at restena.lu     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080103/2f9cbdba/attachment.pgp>