On Fri, 11 May 2001, Nilesh Naik wrote:
> hello friends
Hi,
>
> we have 3-4 branch offices and for our employees
> who keeps on travelling , we want a secured remote
> access environment the remote access environment. for
> which we have decided to deploy ciscoSecure ACS along
> with the secureID Ace/Server
>
> follwing is the mixed list of my queries and our
> requirment , please guide me
>
> requirements :
>
> 1) dial back/call back once user gets authenticated.
I'm not sure where you are in the world, but dial-back after
authentication has some definite weaknesses:
1. Setting up call forwarding on the line to forward to another number for
inbound calls. This isn't possible for an oubound dialer to check, so if
the attacker knows which number to do this on, it's normally a small
social engineering exercise at the local telco, or 2 minutes with a butt
set at the location's network interface (NI) jack. In the US, if you
include residential access for administrators, the NI (unless it's a very
old house that's had no phone work in the last 20 or so years) is outside
the house stuck to the side or back of the building where it's easily
accessible.
2. If you don't use a fully pinnned out serial cable, it's possible to
spoof hangup if the modem at the dial back end doesn't support DTR. If
dial back is to reverse toll charges, this probably isn't a big deal for
you, but if it's to provide some sort of line authentication, then it can
be an issue. Some modems don't hang up quickly (such as older Adtran ISU
128 ISDN modems) and need DTR to be off for much longer than the
traditional < 1 second.
There are 3 fixes for this:
1. Require an additional authentication step after the dial back happens.
2. Use ANI (expensive!) to validate the dialing number prior to initiating
dial back.
3. Use CNID to validate the dialing number prior to initiating dial back
(I've heard it's possible to spoof caller-ID if the device latches on to a
second identifier after going off hook- I'm not sure how feasable this is
from a remote location, or if it requires local line accesss though.)
You could also just live with the risk. If it's dynamic dial-back, then
remember that things like hotels that don't allow direct inbound dial
access to rooms will break your access mechanism.
> 2) traditional userID/password authentication with an
> additional level of security provided by SecureIDtoken
> server and secureID tokens.
> 3) this addtional layer of security provided by
> secureID tokens and token server will be only used in
> the case of remote access.
>
>
> queries :
> 1) Is it possible to use token based authentication
> with traditional radius authentication ,
> what i mean is user will have to enter
> username/password two times once for Radius and
> second time
> user will enter username/OTP passcode
> generated by
> SecureID authenticators,
[I'm possibly misreading this- the second time through I got a
different interpretation-- apologies if I've missed cleaning it up to one
interpretation anywhere.]
You can use the Secure-ID ACE server for RADIUS authentication (with
the caveat that it requires one minute between authentications for a
single user) for token users. Users in the ACE server can have either a
token or username/password authentication method.
If token users always use tokens, and password users always use passwords,
then it's an easy to set up and administer system. If you need "sometimes
they use tokens, sometimes passwords" then it's much more difficult.
> This(above) should also happen with
> dialback/callback , is it possible ? if yes then how
> this authentication will work ?
I know in the past some vendors have touted re-authentication with
dial-back. I don't recall which vendors though. Dialback should be a
fucntion of the access path, not the authentication method. You'll
probably need a second authentication method if you pre-auth the dialup
though, as the one minute interval complicates dial-back using the token
for both dial-in and dial-back auth.
> is the above recommended ? if no what is
> recommended ?
It depends on the requirements. They're not perfectly clear to me at this
point. Re-reading this has made me decide you meant something different
than what I originally read, so please look at my answers about the two
authentication server quesitons and seperate that from the dial-back
issue, then maybe it'll be easier for you to narrow down your questions.
>
> 2) we have decided that we are going to deploy
> ciscosecure ACS with SDI secureID ACE/server.
Your local Cisco rep. will be able to answer all your questions on their
product. Just don't forget that the ACE server can act as a RADIUS server
when looking at authentication methods. It seems to me that you're
deploying two devices that do essentially the same thing, one of which is
necessary to use SecureID. You should also be able to contact RSA and
have both vendors tell you how their products meet your requirements.
> then where we should create the users ? since now
> we have droped the idea of using LDAP central
> directory to store user ID/password whichwe were
> planning to use for authentication and so , i have
> mentioned in my previous mail .
>
> 1) for traditional radius authentication with
> normal
> uid/password .
> and
> 2) for token based authentication with
> sameuid/OTP
> passcode generated by secureID authenticators
>
I'm not sure why you need both? If you mean for different users, then you
can put user/password entries into the ACE server, though you'd have to
check with RSA to see how that affects the number of users you have to
license.
RADIUS servers that support pass-through authentication may save the
per-seat issues if it's still a flaw in the way ACE servers are licensed.
> in cisco ACS native database ? or in the ACE server
> userdatabse ? or in both cisco sever ACS Databse as
> well as ACS servers database ?
> whats the recommended ?
I'd use a RADIUS server, as it gives the ability to use the same
authentication method with multiple products, as well as the ability to
swap out products without recreating the entire user database. Obviously,
ACE users have to be in the ACE server, so keeping two things syncrhonised
isn't fun if you have two seperate RADIUS servers, and license terms would
be the main driver for me to not just use the ACE server as a RADIUS
server, but the RADIUS server and hardware would have to be cheaper than
the extra seat licenses to make me not just use the ACE server.
> 3) How the radius authentication will work along with
> the ACE servers token based authentication ?
Depends on if you're doing RADIUS to the ACE server or ACE to the RADIUS
server. If ACS supports pass through auth to ACE, then you can put the
users there, otherwise you're probably pretty much stuck putting in a
different RADIUS server and passing the ACE users to it, or just using
RADIUS on the ACE server.
> 4) can we have all the following applications
>
> 1) ciscoSecure Access Control Server
> 2) SecureID Ace/Server
>
> running on different hosts,for above senario.
>
> would really appriate if someone guide me
I'm not sure why you need the ACS server if you're just looking for
central authentication? The ACE server does RADIUS, and most everything
Cisco makes will talk RADIUS, so unless there's some large administrative
report benefit to using it, what's the driver for using the Cisco product?
(I have nothing against the ACS server as a product, I just don't see the
need for having two essentially similar products where one is required
because of the tokens chosen.)
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
