Re: Issue: Some possible conflicts between RFC 2865 and RFC 3579 (fwd)

["Alan DeKok" <aland@ox.org>]

Antonio Plaza and Alfonso Valero wrote:
> If an Access-Request is received in a RADIUS server with an
> encapsulated EAP-Message, and the shared secret is different in the
> server and the client, according to the section 3.2 in RFC 3579 the
> Access-Request should be silently discarded, because when the
> Message Authenticator is assessed by the RADIUS server it is
> different from the Message-Authenticator of the sent one, as it is
> calculated using the shared-secret as key. However, according to the
> section 4.3 in RFC 2865, the RADIUS server should send an
> Access-Reject because one attribute (Message Authenticator) is not
> acceptable.

  Yes.  There is some apparent inconsistency, doubly so because RFC
2865 is standards track, and RFC 3579 is information.  The security
considerations section of RFC 3579 doesn't highlight this issue, even
though the behavior of the protocol is changed by RFC 2579.

> We think there is some kind of ambiguous behaviour as the figure
> below shows, so, how should the RADIUS server act in this situation,
> the Access-Request should be discarded or an Access-Reject should be
> sent instead?

  (diagram shows client sending EAP-Message & Message-Authenticator,
where client & server have different shared secrets).

  The short answer is that I've never seen this ambiguity be a problem
in real deployments.  The long answer is given below.

  Before discussing recommended behavior, let's list the behavior of
current deployments:

  (1) If the server was written before RFC 3579 was published, it will
send an Access-Reject.  This is consistent with RFC 2865, and does not
cause interoperability problems with RFC 3579.  However, because the
Access-Reject is signed with the shared secret, the client will
silently discard the packet, as per section 4.2 of RFC 2865.

  (2) If the server was written after RFC 3579 was published, then
either it implements Message-Authenticator, or it does not.

    (a) If it doesn't implement Message-Authenticator, then it will
        send an Access-Reject, and the client will not see the EAP
        session proceed past the initial packet.  The Access-Reject
        will be discarded, as outlined above.

    (b) If the server implements Message-Authenticator, then it will
        silently discard the request, and the client will not see a
        reply.

  At no time will the inconsistency between RFC's lead to different
client behavior.  In all cases, the client will not obtain a valid
response from the server.  And this failure to obtain a valid response
is perfectly consistent with RFC 2865.

  The only effect this inconsistency has in real-world deployments is
the following.  When the client receives an Access-Reject with an
incorrect signature, and no valid Access-Accept or Access-Reject, then
the client may assume that the correct server is alive and responding,
but that the shared secret is incorrect.

  If the client receives no Access-Reject (as per RFC 3579), then it
cannot determine if the failure to receive a response is because the
server is down, or because the shared secret is incorrect.


  Finally, what "should" the client do in the situation you point out?
The only possible recommendation is that it should follow RFC 2865.

  Alan DeKok.

--
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/>