Re: WGLC #357: Authentication Exchanges

On 21.06.2012 06:01, David Morris wrote:
> On Wed, 20 Jun 2012, Julian Reschke wrote:
>
>> On 2012-06-20 06:11, Mark Nottingham wrote:
>> >
>
>> > How about, after those two paragraphs:
>> >
>> > """
>> > A server receiving credentials that are valid, but not adequate to 
>> gain
>> > access, ought to respond with the 403 (Forbidden) status code.
>> > """
>
> Seems to me that 'ought to' should either be 'SHOULD' or 'MAY'?


If it were, that would make the existing implementations 
non-conformant.


My intention with bringing this up at all was to make it clear there 
was an preferred alternative to infinite 401 loops, should the server 
need to use it.


401/407 being the try-again response, indicates new credentials are 
REQUIRED. It *remains* the preferred status when credentials are valid 
but different ones would gain access in a followup request.


403 being the preferred halt status for authn and authz indicating that 
repeating or retrying is not going to be useful.


We need to do this to prevent future auth schemes or implementations 
using 400 or 404 or such status. We have had several proposals just 
since I joined the list this year for creating a whole new status code 
duplicating 403 semantics because people did not understand that on 
first reading of the Drafts.

Simply put 403 says two things:
   1) I checked your credentials, they were fine but you are not allowed 
access here. Go away.
   2) You are not allowed access here. I didn't even bother to check 
your credentials, they won't help. Go away.

  case (1) is when for example Corporate users machine is trying to 
access CEOs private pages. authn passes, authz failed. Only the CEO 
machine allowed to access the CEOs content.

  case (2) is when for example External IP attacker is trying to access 
internal-only resources. IP or something non-authn is the primary authz 
check and 403 prevents credentials leakage to the attacker.


  Either way authz failed AND the server policy desires the user 'never' 
to re-try.

Important note: this above is an explicit server policy, not a protocol 
mandatory response.


AYJ

Received on Thursday, 21 June 2012 02:55:35 UTC