[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
> 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
> 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
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/no EAP-Message attribute
Access-Reject/no EAP-Message attribute
Access-Challenge/no EAP-Message attribute
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
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.