On Thu, 12 Oct 2000, Vin McLellan wrote:
Hi Vin,
> Shouldn't the "cost-effectiveness" of vendor support also be
> evaluated in the context of a professional risk assessment? Access to
Excellent point!
> Paul Robertson <[EMAIL PROTECTED]> noted some of the traditional
> problems with some "call-back" modems. Even when they work correctly,
> however, call-back depends on the integrity and security of the phone
> company's internal computers and switches. These have, by numerous hackers,
> been subverted and tweaked. Tapping a phone line, while overtly "criminal"
> and uncool, is also technically trivial.
It's worse, I'd forgotten about the "call and have the line forwarded"
case- which has been used by at least one competing business (I believe a
plumber in Florida?) and would certainly make dial-back useless (get
schmuck to auth, host computer calls you back instead, and you call him
back to get any further authentication...)
> The Holy Grail -- and today, often one of the Golden Promises that
> spur the PKI advocates, me among them, toward our Golden Future.
*grumble* no good infrastructure, *grumble* untrused OS and keys *grumble*
believe it when I see it....
> Unfortunately, it seem that contemporary organizational trends --
> and echoes of those trends in corporate network tech: fewer internal
> firewalls, cross-realm authentication, single sign-on, etc. -- have brought
> down many of the architectural barriers that used to constrain internal
> roaming by even authorized users.
Actually, it's my opinion that in the last 24 months, building internal
firewalls has become acceptable because of things like connections to
business partners and Internet access at different sites. It just takes
the right spin and approval isn't too difficult in most environemnts.
> The ACE/Server's administrative capabilities have been enormously
> upgraded in recent versions (v.4.X) -- but it is still not trivial to set
> it up the RSA authentication server, or to manage it over time.
No to mention the lack of Linux client library support unless you want to
pay an exorbitant consulting fee. :(
> RSA's patents on time-synch tokens focus on the mechanisms the
Oh yes, RSA and patents- now the algorithm's patent has expired, I
suppose I'll never get my answer ;)
> records -- the temporal difference between what each token and the Server
Hmmm, first valid use of "temporal difference" in a firewalls post?
> I think the ACE/Server's procedural rules would block the obvious
> "time shift" attacks: no SecurID token-code can be used twice, and the
> ACE/Server will not accept a token-code generated with a "Current Time"
> earlier than those it previously accepted.
What about locations with two ACE servers? Would that only work for
the first authentication to the backup server, or for the time period
between the last valid (or even invalid) authentication and the next per
server? Does putting in a second ACE server for redundancy open me up to
a replay or time drift attack that having only a single server doesn't?
If that's the case, does it make sense to set one host to synch time off
the other if they both don't have good clocks?
> If the Server's clock suddenly picked up a minute or two --
> anything less than ten -- the ACE synchronization system would simply
> absorb it as "drift" in the respective tokens (relative to the inherent
> trustworthy server) and adjust. This would force all SecurID token-holders
> to resynch -- which essentially means it would demand two valid (if
> off-synch) token-codes. That would irritate everyone (and everyone would
> probably blame the tokens), but the ACE/Server would keep serving and
> validating authentication calls.
Yeah, but if it picks up a few hours, things get really bad, right?
> While it might make things easier, I suspect -- to judge by the
> many years non-GMT time was the norm for installed ACE/Servers -- that
> "correct time" is useful, but not necessary, for properly attributing
> audited acts to a given token-holder.
I think the issue isn't "correct" time so much as accounting for bad
hardware.
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.]
