[VPN] Cryptocard [Off-topic]

[Siddhartha Jain]

I'll try to point out answers to some issues you've raised. However, that
doesn't mean that I opine PKI roll-outs are smooth :)

>
> --The obvious, you need a PKI.

Yes, but PKI can be used to secure other apps in the environment that
support SSL. You may have Oracle client-server app in which case you can
turn on SSL and use the same token for auth. Same goes for any client-server
app that allows SSL and I think most widely used apps, today, support SSL.
To my mind, this gives a virtual SSO solution.

> --Who maintains it, who administers it, who pays for it (not too cheap),
what
> product do you go with/do you build your own, is it going to be public
> facing, does it need to be audited, do you need special facilities for it,
> and on and on....

Definitely, some thought needs to go into deploying PKI. However, some needs
to maintain, administer and pay for that Keon server and those keyfobs too
:) I believe the same guys would foot the bill for PKI too.


> --How do you distribute certificates to Joe User without making his eyes
glaze
> over with intructions (usually anything beyond 5 steps is deemed painful)

I used iPlanet web-based certificate enrollment long time back. And used MS
Cert server recently. Though, I am no fan of MS, but the cert enrollment was
pretty easy. The user is provided with very choices thus minimizing the
chances of the user screwing up something.

> *and* make sure it's Joe and Joe alone that gets the cert?

True, the basis for enrollment is again good ol' username and password. But
if you allowed the initial enrollment process in a controlled environment
(from the corporate network only or some other mechanism could be thought of
since its a one-time procedure)

> --How are revokations and recoveries handled and who does it (and who
is/are
> his backup(s))?

Revocations - If a user leaves the org, the HR drone deletes him from the
corporate directory thus revoking his/her cert too. Or if the user sends an
alert saying they've lost the token, the certserv admin can revoke the cert.
Recovery - MS Cert serv shows an option for a recovery agent. The cert admin
should do the recovery and his backup could be other people in the security
team. I don't think recovery is a technical problem.

> --Who handles the physical USB token part and who handles the cert part
(ie,
> what happens when a user leaves it in the washing machine or loses it at a
> hotel)?

The user calls/mails and informs of the loss. Cert admin revokes cert. The
cert and token, both, are now unusable.

> --Related to the above, how do you protect a stolen/lost USB token with a
> valid cert on it?

A token (to the best of my knowledge) cannot be tampered with. So you can't
crack it and get the private keys out of it. Besides, a lost token wouldn't
be usable because the thief still needs the PIN number protecting the
private keys.


> If user/pass, what protocol and authentication backend do
> you use?  If token based--why not just use the token to begin with?  If
you
> choose NTLM, what about people that don't log on the NT domain(s)?  If you
> choose LDAP, (1) do you have a solid, central LDAP and (2) how do you
publish
> the cert, what field name do you give it, what encoding do you use, etc.?

I configured it for VPN 3000 about a year back for a client. The box was
configured for certificate authentication, so no other authentication
protocol comes into picture. Later, we added user/pass auth also for
additional protection.

> --What about the people who are stuck with NT 4.0 and can't use USB
tokens--do
> you force an upgrade to W2K or XP?  What about those that insist on using
> their SUN Sparc workstation because their core apps depend on it?

True. Nothing much you can do about that.

> --Can the apps that you want a cert for handle certs to begin with?
(radius
> support is much more common than PKI support).

Yes, if the app can support SSL. Or can be tunneled through an SSL-lizing
app. Ofcourse, RADIUS is much more supported.

> It goes on and on--believe me--and maybe you've experienced much of the
above
> yourself.  PKI is oftentimes the most administratively frustrating
> application of all.  It's a shame, really, because it's quite simple in
it's
> essence, but the real world problems can be daunting, to say the least.
> Adding to the above, PKI certificates seem to have this mysterious quality
to
> them that even many IT professionals just refuse to grasp.  You try to
tell
> them that "it's a 4K file that doesn't want to hurt you", but they just
can't
> understand it, for whatever reason.  This makes PKI the target of anything
> that goes wrong--page won't load, PKI; user can't get in via VPN, PKI;
user
> can't get on to the NT domain, PKI; user's car batterey goes dead, PKI.
> Sorry, now I'm venting...  Anyway...

> As much as I like PKI and USB tokens, I have to give warning that it can
sound
> much, much simpler than it really is.  But, in truth, I've always worked
for
> very big organizations that, from an IT perspective, are more like 100s of
> small companies that all have the same name.  If you don't face the
> aforementioned potential problems, then maybe you have a good chance of
> pulling it off--I just haven't been so lucky.

I agree that rolling out PKI is not an out-of-the-box solution as many
vendors like to present it but I think we need to push it to customers. The
more  it is deployed, the more vendors will be forced to smoothen the rough
edges and make it easier for orgs to deploy it. Unless this happens, the PKI
solutions won't mature.


Siddhartha


>
> --Willie
>
>
>
> On Sunday 31 August 2003 11:50 am, Siddhartha Jain wrote:
> > Hello People!!!
> >
> > Do you think certificate storing USB tokens like Rainbow or Alladin
would
> > be safer? and better too. For one, you don't need a centralised server
and
> > the use of certificates offers better security than regular two factor
> > tokens?
> >
> >
> > Siddhartha - Muscat 23.36N 58.38E
> >
> > ----- Original Message -----
> > From: "Joel M Snyder" <Joel.Snyder at Opus1.COM>
> > To: "Travis Watson" <rtwatson13 at yahoo.com>
> > Cc: <vpn at lists.shmoo.com>; "Rudi Pierquin" <pierudi at yahoo.fr>
> > Sent: Sunday, August 31, 2003 9:34 PM
> > Subject: Re: [VPN] Cryptocard
> >
> > > >I don't know if cryptocard is
> > > >peer-to-peer or master-slave (Joel, can you answer
> > > >this for us, please?), but I would be nervous about a
> > > >master-slave setup if that's what it is.
> > >
> > > Yes, CryptoCard has the same style as Safeword---centralized
knowledge,
> >
> > but
> >
> > > distributed knowledge.  In fact, I have had good experiences with
> > > Safeword
> >
> > as
> >
> > > well in recent years (got a pile of tokens in front of me as I speak),
> > > but never used them in production because they don't support OpenVMS
as a
> >
> > server.
> >
> > > There is a human-factors issue with distributed servers and
CryptoCard.
> > > CryptoCard is often used in "reduced input" mode, which means that the
> >
> > server
> >
> > > keeps some state between queries; it lets the user avoid putting in
the
> > > challenge if you (the network manager) don't want to require it.  In
> >
> > essence,
> >
> > > in reduced input mode, the token & the server kind of agree on what
the
> > > challenge will be the next time, and the token shows it---if the
server
> >
> > asks
> >
> > > for the same challenge that the token is giving, then the user just
> >
> > presses
> >
> > > ENTER instead of putting in the challenge.   (for those of you who
care,
> >
> > the
> >
> > > next challenge is based on additional bits out of the encryption that
the
> > > CryptoCard does but which are not displayed, so it is under control of
> > > the server, not some synchronized algorithm like SecurID uses.)
> > >
> > > If you flop around between servers, then you can't use reduced input
(or,
> >
> > more
> >
> > > precisely, the user will perceive that they always have to enter the
> > > challenge), so most people who use CryptoCard tend to have multiple
> >
> > servers,
> >
> > > but the servers are ordered (i.e., failover, not active load sharing)
so
> >
> > that
> >
> > > the same card tends to hit the same server all the time.  That doesn't
> >
> > mean you
> >
> > > can't load balance them across regions, just that your users will be
> >
> > happier if
> >
> > > you don't.
> > >
> > > So that's a long answer to the question.  The short answer is "yes,
you
> >
> > can
> >
> > > have lots of servers."  It's just that when you set it up, you need to
be
> > > cognizant of the human interface issues related to the product as well
as
> >
> > the
> >
> > > IT reliability issues.
> > >
> > > But I would agree with Willie 100%: I like the idea that I don't have
a
> >
> > single
> >
> > > server which has the "core knowledge;" I can distribute the knowledge
> >
> > around by
> >
> > > sharing the token's secret among a bunch of different servers using
> >
> > CryptoCard
> >
> > > and that makes it more attractive to me.
> > >
> > > jms
> > >
> > > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> > > Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
> > > jms at Opus1.COM    http://www.opus1.com/jms    Opus One
> > > _______________________________________________
> > > VPN mailing list
> > > VPN at lists.shmoo.com
> > > http://lists.shmoo.com/mailman/listinfo/vpn
> >
> > _______________________________________________
> > VPN mailing list
> > VPN at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/vpn