Josh Howlett wrote:

That's certainly a feature of some Cisco WAPs.

If anyone knows of a supplicant that does anything *useful* with EAP-Notification (like, you know, notify the user) then that would be interesting to hear :-)

wpa_supplicant supports it; changelog says it was added back in May 2005 * display EAP Notification messages to user through control interface with "CTRL-EVENT-EAP-NOTIFICATION" prefix Whether the GUIs that sit on top of it take notice is another matter. windows XP supplicant displays the Reply-Message attribute in one of those annoying yellow popup bubbles, but only for straight CHAP ?! Mac OSX logs the notifications in the system log... Though given that 90% of mac users probably don't know what a terminal window is... not that much use ! It'd be interesting to see if there was any way to get hooks into the eapol client, then you could transfer the EAP notifications over into the growl Notification framework. Give you a neat mechanism to berate your Mac users for AUP transgressions :) --- Alan, Any chance the rlm_eap failure codes/verbose error messages could be made available as attributes in the request list ? --- Thanks, Arran

josh.

...

-----Original Message----- From: freeradius-users-bounces+josh.howlett=ja.net@lists.freeradius. org [mailto:freeradius-users-bounces+josh.howlett=ja.net@lists.fre

eradius.org] On Behalf Of Arran Cudbard-Bell

...

Sent: 03 January 2008 12:50 To: FreeRadius users mailing list Subject: EAP Notification

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 ?

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

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

Stefan Winter wrote:

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.

Thats the pattern that makes logical sense, unfortunately what actually happens is : (supplicant) (NAS) (RADIUS-Server) ... EAP ... <------------------ Access-Accept with EAP-Message and Reply-Message <--------------- EAP-Success with content of EAP-Message <--------------- EAP-Req/Notification (containing Reply-M) ---------------> EAP-Resp/Notification --- NAS discards EAP-Resp, no forward to Server --- The NAS does discard the Notification response, which resolves RFC3579 2.6.5[1]. By sending the Notification post EAP-Success, it contravenes RFC3748 5.2, but does resolve RFC3579 2.6.5[2], as there should be no further packets within the EAP conversation. I'm actually rather surprised the supplicant supports this behaviour; I would have expected it to silently discard the Notification as authentication effectively completed with the EAP-Success packet. RFC2579 States: 2.6.5. Displayable Messages The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet. So really *any* interpretation of the Reply-Message by the NAS is wrong. Instead the RADIUS server, on detecting a potential displayable message in the formulated RADIUS Access-Accept/Access-Reject packet; should send a notification packet encapsulating the displayable message, and wait for a notification response from the supplicant, prior to sending the final EAP-Success/Access-Accept,EAP-Failure/Access-Reject packet. It should also filter any displayable messages in the formulated RADIUS response.

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.

Looking at 'attrs.access_reject' in the current CVS head it appears that this is not enforced, and that it explicitly allows a Reply-Message attributes in Access-Reject packets. 1 # 2 # Configuration file for the rlm_attr_filter module. 3 # Please see rlm_attr_filter(5) manpage for more information. 4 # 5 # $Id: attrs.access_reject,v 1.1 2006/11/22 21:48:35 aland Exp $ 6 # 7 # This configuration file is used to remove almost all of the attributes 8 # From an Access-Reject message. The RFC's say that an Access-Reject 9 # packet can contain only a few attributes. We enforce that here. 10 # 11 DEFAULT 12 EAP-Message =* ANY, 13 State =* ANY, 14 Message-Authenticator =* ANY, 15 Reply-Message =* ANY, 16 Proxy-State =* ANY It is possible in FR2-Beta to satisfy the RFC's using FR's conditional language... something like: post-auth { if("%{reply:EAP-Message"}{ update reply { Reply-Message -= } } } Though thats a guess, as the man pages are unclear as to how the new filtering and enforcement operators are to be used.

Greetings,

Stefan

Regards, Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900