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

[Avi Lior <avi@bridgewatersystems.com>]

Hi Bernard,

See inline please.  I have comments throughout.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Saturday, March 05, 2005 5:27 PM
> To: Avi Lior
> Cc: Alan DeKok; radiusext@ops.ietf.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
> 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?

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
right?

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
before.  

 
> > 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;
-etc...

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

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