[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: [Pana] RADIUS Access-Reject and NAP/ISP authz
FYI, more "Access-Reject doesn't _really_ mean Access-Reject"
nonsense, this time (perhaps predictably) from the PANA WG. I
particularly like case #2, where L2 access is denied but IP access
is magically provided (avian transport, maybe?). We _really_ need
to do something about this...
MORAND Lionel RD-CORE-ISS <> supposedly scribbled:
> 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 : pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] De la
part
>> de Alper Yegin Envoyé : vendredi 18 mars 2005 22:37 À :
>> pana@ietf.org 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
>> Pana@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pana
>>
>
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www1.ietf.org/mailman/listinfo/pana
Hope this helps,
~gwz
Why is it that most of the world's problems can't be solved by
simply
listening to John Coltrane? -- Henry Gabriel
--
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/>