RE: When to Access-Reject vs. Silently Discard

[Avi Lior <avi@bridgewatersystems.com>]

Hi Alan,

Okay I agree with your $0.02. So we should do a reject in RADIUS Digest in
this case.

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Wednesday, April 06, 2005 1:03 PM
> To: radiusext@ops.ietf.org
> Subject: Re: When to Access-Reject vs. Silently Discard
> 
> 
> 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/>
> 

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