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 ([EMAIL PROTECTED])
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
