Re: Access-Accept & permitted EAP messages

[Bernard Aboba <aboba@internaut.com>]

>   Reading RFC 3579, I see that EAP-Request isn't permitted in
> Access-Accept, but it's silent on EAP-Response.
>
>   I ask this because I've recently seen an implementation where an
> invalid Access-Accept is sent in the middle of an EAP session, which
> contains EAP-Response.  The NAS implementation is problematic, too, as
> it thinks the user is "accepted", and sends Accounting-Request for
> that session.

I believe that RFC 3748 prohibits the NAS from forwarding an EAP-Response
to the user, since it is supposed to check the Code, Identifier and Length
fields prior to forwarding.  However, with respect to the Accept/Reject
decision, I think this is correct.

>   The Access-Accept doesn't contain EAP-Success or any MPPE keys, so
> no wireless traffic should pass, but it's still an odd situation.

RFC 3748 allows the EAP peer to figure out that access has been provided
based on lower layer info, provided that the method concluded
successfully.  However in this case the conversation will probably
stall because the EAP-Response is either not delivered or is dropped by
the peer. The lack of keys will cause communication to fail
between the NAS and peer anyway.

>   Section 2.6.3 of RFC 3579 talks about combinations of messages that
> SHOULD NOT be sent by the RADIUS server.  I don't see EAP-Request or
> EAP-Response listed under Access-Accept, which is odd.

This issue is covered in RFC 3748 with respect to authenticator
forwarding.  Also, RFC 3579 does say that a RADIUS server cannot
act as an EAP peer, which implies that it doesn't send EAP Responses.

> Maybe we want to add something to the issues & fixes, saying "the
> only EAP packet allowed in Access-Accept is EAP-Succes".  Any other
> EAP messgae MUST be interpreted as a reject"

I don't think we want to talk about interpretation of EAP messages within
RADIUS, since RFC 3579 states that the Accept/Reject indication is
considered definitive.  RFC 3748 does allow an EAP conversation to
terminate successfully without an EAP Success under some conditions, so
I'm not sure we can prohibit this.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>