[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)
See inline please. I have comments throughout.
> -----Original Message-----
> From: Bernard Aboba [mailto:email@example.com]
> Sent: Saturday, March 05, 2005 5:27 PM
> To: Avi Lior
> Cc: Alan DeKok; firstname.lastname@example.org
> Subject: 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?
No. That is the problem we are now facing. Authorize-Only messages maybe
sent by the NAS without receiving a CoA.
This makes perfect sense.
Here is an simple example. If an already authenticated user wants to
establish a new call VoIP call etc... The NAS can then Authorize that call
by issueing an Access-Request Authorize-Only. No need to autenticate again
Prepaid does that as well. Send an Access-Request Authorize-Only to get
more quota. No need to Authenticate again right?
So in the context of these example it would be reasonable to allow for an
Access-Reject to mean that the AAA rejects to Authorize right?
Note in prepaid we return an Access-Accept with a quota which indicates no
more resources (so I don't use Access-Reject). So likewise we can use the
same for the first example. But Access-Reject ought to work just as well.
In fact, philosophically returning something in Access-Accept to indicate
that "you can't do what you asked for" is like returning EAP-Failure in an
Access-Accept -not a good idea(see good discussion on this later).
> > 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?
3576 requires a very small set of attribute to be stored. If I have to
store everything that would be harder. I sort of eluded to this many time
> > 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?
I think we need to address what is coming up on us. SO mulitple
Authorization per session for different reasons:
-authorization for new flows (voip);
-prepaid quota management;
-authorization for services such as one-time-events introduce by Diameter
prepaid and RADIUS prepaid;
> > Also related to this discussion - I ran into this in Pana :
> > pana-pana-07
> > "Within separate NAP and ISP authentication, the NAP
> > 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:
Yes I re-read that just before I sent the last message.
It is a problem. We need to address it.
If I send the EAP failure in an Access-Reject, then the session is dead.
If I send the EAP failure in an Access-Accept, then I am also stuck.
Although this is not strictly prohibited in 3579!!!
So either PANA folks are missing something or we AAA folks (RADIUS and
DIAMETER) have to re-think our view of reality.
I would like to chat about this further with you and any interested people.
I raised this as an issue in my RADIUS-PANA draft.
> 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-Reject/EAP-Message/EAP Success
> Access-Reject/no EAP-Message attribute
> Access-Challenge/EAP-Message/EAP Success
> Access-Challenge/EAP-Message/EAP Failure
> 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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.