[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Access-Reject (was RE: Comments on draft-carroll-dynmobileip-cdma -04.txt)

> But if the server which just received an Authorize-Only packet didn't
want
> to do the re-authorization requested?

"Authorize Only" Access-Requests are only generated as the result of a
CoA-Request or Disconnect-Request, right?  So presumably the server that
initiated the request had an idea that it wanted a re-authorization, no?

> It could send an Access-Reject if we allow the Access-Reject to mean I
> don't want to re-authorize.  Full stop.
>
> Failing that, it will have to send an Access-Accept with _all_ the
> previously sent authorization attributes.

Isn't it likely that an RFC 3576 implementation would have stored those
attributes anyway?  Or are there circumstances where it might not do
that?

> I can live with the traditional meaning of Access-Reject, but I do have
> issues with how we make it easier and more realistic to develop RADIUS
> extensions.

I think that's more of a RADEXT charter issue, no?  Or are you saying we
need to build more extensibility into the protocol itself?

> Also related to this discussion - I ran into this in Pana : pana-pana-07
>
>    "Within separate NAP and ISP authentication, the NAP authentication
>    and the ISP authentication are considered completely independent.
>    Presence or success of one should not effect the other.  Making a
>    network access authorization decision based on the success or failure
>    of each authentication is a network policy issue."
>
> If EAP-failure can only be carried in an Access-Reject then if one of
> these enetities rejects the authentication, and the other accepts the
> authentication we can get into a situation where:
> NAS receives an Access-Accept
> NAS receives an Access-Reject
> And the session is allowed to go on.

RFC 3579 states that the RADIUS command determines the outcome, not the
embedded EAP packet (Success/Failure).  So an Access-Reject always results
in denying access, even though the RADIUS server might succeed in
confusing the EAP peer by sending an Access-Reject/EAP-Success.

Here's what RFC 3579, Section 2.6.3 says:

2.6.3.  Conflicting Messages

   The NAS MUST make its access control decision based solely on the
   RADIUS Packet Type (Access-Accept/Access-Reject).  The access control
   decision MUST NOT be based on the contents of the EAP packet
   encapsulated in one or more EAP-Message attributes, if present.

   Access-Accept packets SHOULD have only one EAP-Message attribute in
   them, containing EAP Success; similarly, Access-Reject packets SHOULD
   have only one EAP-Message attribute in them, containing EAP Failure.

   Where the encapsulated EAP packet does not match the result implied
   by the RADIUS Packet Type, the combination is likely to cause
   confusion, because the NAS and peer will arrive at different
   conclusions as to the outcome of the authentication.

   For example, if the NAS receives an Access-Reject with an
   encapsulated EAP Success, it will not grant access to the peer.
   However, on receiving the EAP Success, the peer will be lead to
   believe that it authenticated successfully.

   If the NAS receives an Access-Accept with an encapsulated EAP
   Failure, it will grant access to the peer.  However, on receiving an
   EAP Failure, the peer will be lead to believe that it failed
   authentication.  If no EAP-Message attribute is included within an
   Access-Accept or Access-Reject, then the peer may not be informed as
   to the outcome of the authentication, while the NAS will take action
   to allow or deny access.

   As described in [RFC2284], the EAP Success and Failure packets are
   not acknowledged, and these packets terminate the EAP conversation.
   As a result, if these packets are encapsulated within an
   Access-Challenge, no response will be received, and therefore the NAS
   will send no further Access-Requests to the RADIUS server for the
   session.  As a result, the RADIUS server will not indicate to the NAS
   whether to allow or deny access, while the peer will be informed as
   to the outcome of the authentication.

   To avoid these conflicts, the following combinations SHOULD NOT be
   sent by a RADIUS server:

      Access-Accept/EAP-Message/EAP Failure
      Access-Accept/no EAP-Message attribute
      Access-Accept/EAP-Start
      Access-Reject/EAP-Message/EAP Success
      Access-Reject/no EAP-Message attribute
      Access-Reject/EAP-Start
      Access-Challenge/EAP-Message/EAP Success
      Access-Challenge/EAP-Message/EAP Failure
      Access-Challenge/no EAP-Message attribute
      Access-Challenge/EAP-Start

   Since the responsibility for avoiding conflicts lies with the RADIUS
   server, the NAS MUST NOT "manufacture" EAP packets in order to
   correct contradictory messages that it receives.  This behavior,
   originally mandated within [IEEE8021X], will be deprecated in the
   future.

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