Subject: RE : [Pana] RADIUS Access-Reject and NAP/ISP authz

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Mon, 21 Mar 2005 13:24:14 +0100

Hi Alper,

I think that we should carefully consider the case of NAP/ISP separate authentications.
The idea is to allow two different administrative domains (the local access network and the distant ISP) to authenticate the PaC, based on distinct credentials. The NAP authentication may be required to provide L1/L2 access and related local services. The ISP authentication is required to provide IP access services.
Both authentications are based on an end2end EAP dialogues between the PaC and the appropriate AAA server (i.e. NAP AAA server or ISP AAA server), over PANA and the back-end AAA protocol (RADIUS or Diameter).
As a consequence, the PAA will have two distinct dialogues with both AAA servers. The outcome of a given dialogue (authentication success or failure) should not have to impact the dialogue with the other one.

Therefore, in the RADIUS case, depending of the local NAP policies:

1/ If the ISP authentication failed, the PAA may either:
- Send an Accounting-Start message the NAP AAA server only, indicating that a L1/L2 access is provided to the PaC.
- Deny the network access

2/ If the NAP authentication failed, the PAA may either:
- Send an Accounting-Start message to the ISP AAA server only, indicating that the PaC is provided with IP access.
- Deny the network access

3/ If both authentications succeded, an Accounting-Start message will be sent to each AAA server.

I don't see any problem with this approach. I don't see why an Accounting-request would be sent to an AAA server that would have rejected the PaC.

By the way, on the following issue raised by Avi:

"There seems to be a conflict between RFC3579 and PANA when multiple authentication is used.

   This is what RFC 3579 says:

   The conversation continues until either a RADIUS Access-Reject or
   Access-Accept packet is received from the RADIUS server.  Reception
   of a RADIUS Access-Reject packet MUST result in the NAS denying
   access to the authenticating peer.  A RADIUS Access-Accept packet
   successfully ends the authentication phase.  The NAS MUST NOT
   "manufacture" a Success or Failure packet as the result of a timeout.
   After a suitable number of timeouts have elapsed, the NAS SHOULD
   instead end the EAP conversation.

   This is clearly against the PANA specification.  Which allows one AAA
   authentication to fail and the other to succeed."

I think that this actually a non-issue. We could consider that the access is authorized due to the reception of "at least" one Access-Accept. As I read the RFC 3579, I understand that within a RADIUS dialogue, the NAS must not open the door after the reception of an Access-Reject. It's fine and correct for me. But it does not preclude to open it based on the reception of a Access-Accept within another dialogue. And the case of multi-authentication was not covered by the RFC 3579.

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Alper Yegin
> Envoyé : vendredi 18 mars 2005 22:37
> À : [email-masked]
> Cc : 'Avi Lior'
> Objet : [Pana] RADIUS Access-Reject and NAP/ISP authz
> 
> 
> 
> Issue as discovered in draft-lior-pana-radius-00.txt:
> 
> When NAP/ISP separate auth is being carried out, even if one 
> of the auths has failed, PANA session may still "succeed" 
> (based on local policy decision). In that case, sending a 
> RADIUS Accounting Start to the AAA server that had Rejected 
> the client would confuse that server.
> 
> I think the above issue is valid based on the current PANA 
> specification.
> 
> IMO, what we failed to explicitly capture in the base 
> specification is, for PANA session to succeed, minimally the 
> ISP authentication must succeed. After all, it is the "ISP" 
> that provides the "IP access service." The NAP authentication 
> is in the picture just to let PaC access differentiated 
> (e.g., gold, silver, bronze) "L1/L2" services if it has a 
> separate account with the NAP. Otherwise, a NAP account by 
> itself is not sufficient get Internet connectivity.
> 
> And, a AAA server that hasn't authorized the requested 
> service must not receive an accounting start message. If ISP 
> auth has succeeded, PaC's IP access is authorized, and ISP's 
> AAA server gets notified. If ISP auth failed, all bets are 
> off. If ISP auth succeeded, and NAP failed, IP access is 
> granted but PaC does not get any differentiated service from 
> the NAP (L1/L2); only ISP's AAA server receives the 
> accounting start message. 
> 
> Makes sense?
> 
> Alper
> 
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 22 Mar 2005 14:08:55 +0100

Hi Lionel....

Basically  if some kind of service is finally provided then send an 
Accounting-Start message to AAA server that granted the service,  right?.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Thu, 24 Mar 2005 17:42:01 -0800

Hi Lionel,

> - Send an Accounting-Start message the NAP AAA server only, indicating
> that a L1/L2 access is provided to the PaC.

Since within the scope of PANA we are only dealing with the "IP access",
imo the only option in this case must be the denial of the service.

Alper