EAP Notification

[Arran Cudbard-Bell]

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 at sussex.ac.uk)
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08 
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900