Re: When to Access-Reject vs. Silently Discard

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

Avi Lior <avi@bridgewatersystems.com> wrote:
> In the RADIUS Digest thread (Issue 79) when the Server detects that the NAS
> is trying to authenticate a realm for which it is not authorized we need to
> "reject" the authentication.   This can be done by either Access-Reject or
> Silently Discarding the packet.  SO the question is which one is correct?

  I would back up, and say when do we discard, versus send reject?

 - attempted security breaches (bad Message-Authenticator, unknown
   client) result in the packet being discarded.

 - failed authentication or authorization results in Access-Reject
   (bad password, not permitted to use requested services, etc)

> Its not clear:  for example if Message-Authenticator(80) does not validate
> (as per 3579) we silently discard.  When we detect a lying NAS again as per
> 3579 we generate an Access-Reject:   "Where a match is not found, an
> Access-Reject SHOULD be
>  sent, and an error SHOULD be logged."

  Sending Access-Reject when (NAS-IP-Address != source IP) would break
a LOT of deployments.  And it's a SHOULD, not a MUST.


  For the case of a NAS authenticating for a realm it's not authorized
to use, we need to ask if it's a security problem or failed
authorization.  The answer to that question will tell us how to handle
this case.

  My $0.02 is that if the packet contains a valid
Message-Authenticator, then an Access-Reject should be sent, AND an
error message logged saying that the NAS is misconfigured, or may be
compromised.  We "know" it's the right NAS, because it has the right
source IP and shared secret, which is the only way to identify any NAS.

  If the packet doesn't contain a Message-Authenticator, then the
answer is more complex.

  In this case, I believe that the packet does contain
Message-Authenticator.

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