Subject: Re: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP

From: "David Mitton" <[email-masked]>
Date: Mon, 01 Nov 1999 11:01:06 -0500

I think it's a great idea.
There's an existing implementation that does a similar thing:
         Ascend-Require-Auth (201) 0=no, 1=yes

Your proposal allows the NAS to negotiate the authentication 
techniques.  You may want to consider allowing the specification of several 
types.  And don't forget EAP.

         Dave.

At 09:39 PM 10/26/99 +0000, Barry James wrote:

>Does it make any sense to have an attribute that will allow the
>specification of authentication types before modem negotiation via the
>call check mechanism?  That is to say, one good use of the call check
>mechanism is to have the NAS send the Access-Request with Service-Type =
>Call Check and User-Name = <DNIS> and to have the RADIUS server send back
>and Auth-Type specifying what type of authentication mechanism should be
>used for this call.
>
>Most NAS gear support a default authentication type.  For those users of
>RADIUS that resell ports to ISPs or other customers and need to support
>multiple customers dialing into a bank of NAS's it keeps us from having to
>dedicate NAS gear to specific customers (ie one customer uses PAP and
>another uses CHAP, etc).  I think it would be very useful (we do it here
>now) to be able to send back in the Access-Accept something like Auth-Type
>= Auth-CHAP so that the NAS will initiate a CHAP negotiation with the
>customer, while sending back an Auth-PAP will cause the NAS to initiate a
>PAP negotiation.
>
>This model works well for port-resellers and others. A possible definition
>might include:
>Auth-None
>Auth-Any
>Auth-Default
>Auth-PAP
>Auth-CHAP
>Auth-MS-CHAP
>
>Thoughts?
>
>Regards,
>Barry
>
>Barry L James            | Never doubt that a small group of
>IP SWAT                  | thoughtful, committed citizens can
>Level 3 Communications   | change the world.  Indeed, it's
>http://www.level3.com    | the only thing that ever has.
>Member IEEE, AAAI        | #include <std_disclaimer>
>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Consulting Engineer, Nortel Networks           978-288-4570 Direct
Carrier Packet Solutions                       978-288-3030 FAX
Billerica, MA 01821                     [email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Barry James <[email-masked]>
Date: Mon, 1 Nov 1999 19:37:43 +0000 (GMT)

Thanks Dave.  Actually, in my current setup I use Ascend-Require-Auth and
the Auth-Type attributes to do this now during (what I call) Tier-1
negotiation.  I use the Ascend-Require-Auth to help in setting up outage
policies such that if a customer's RADIUS server fails and they will be
down for a period of time, we may set Ascend-Require-Auth to No,
effectively setting an outage policy to "accept all on this DNIS," until
their RADIUS server is functional again.  

Since Tier-1 negotiation only happens between the NAS and my proxies in
the gateways a down customer premise (CP) RADIUS server doesn't affect
this model.  I also use a 2000ms timeout on Tier-1 negotiations.  And by
using this 2-tier authentication model, one can check global session
limits (or whatever you want to do) *before* a call is accepted (that is,
before the person dialing in hears modem tone) and by sending back an
Access-Reject, the NAS may post a busy signal to the caller.  In areas
where all calls are toll calls (eg Europe) this is a real benefit to the
customer.

Thanks for your input!

Regards,
Barry

-

---

From: Dalia Geller <[email-masked]>
Date: Fri, 05 Nov 1999 11:27:42 -0800

Barry, in the event that the customer's Radius server is down, and you set :

Ascend-Require-Auth to no

in your proxy server, what authorization data do you apply to that call ?

I.e.; ip address, etc. Do you define default authorization data in the
customer profile for the DNIS number that you then apply to every call for
that DNIS number (in the event that a 2nd authentication is not required) ?

Thanks and regards,
-Dalia

-

---

From: Barry James <[email-masked]>
Date: Fri, 5 Nov 1999 21:55:27 +0000 (GMT)

Dalia,

	Actually, we have two mechanisms to use for this.  The first, and
the one we actually use in production, is a configuration setting in the
RADIUS server that directly reflects an object appropriately called
"Outage Policy."  This simply sets the RADIUS server in "Accept All" mode
where any call placed to the customer's DNIS will cause the proxy to send
an Access-Accept to the NAS (after internal parameters have been
satisified and it only applies to the one customer, of course).  However,
in both cases, it's really a blind acceptance. That is to say, anyone
dialing in on that DNIS will forgoe any proxying to CP RADIUS servers and
the proxy will simply send an Access-Accept to the NAS. This is
accomplished either through the first method mentioned above, which
doesn't really care about Tier-1 transactions (except for some internal
specifics) and takes place in Tier-2, or via the Tier-1 transaction which
signals to the RADIUS server that this customer (mapped via the DNIS)
wishes that all calls to a given DNIS be accepted.  The default "Outage
Policy" is to reject if a CP RADIUS is down.
	Both of these methods fall short of any good security (except
obscurity), but they've been created in the event that a customer's RADIUS
goes down but they do not want their nationwide customers to suffer while
they restore service.
	In this thread, I'm not really suggesting implementing/introducing
the *require-auth* attribute.  It's the Auth-Type attribute with
previously mentioned corresponding values that I feel would be a great
benefit when vendors wish to implement the call check feature of the new
draft.

Regards,
Barry

-