Skip to Content.
Sympa Menu

assurance - RE: [Assurance] Failed Authentication Counter Strawman

Subject: Assurance

List archive

RE: [Assurance] Failed Authentication Counter Strawman


Chronological Thread 
  • From: "Rank, Mark" <>
  • To: "" <>
  • Subject: RE: [Assurance] Failed Authentication Counter Strawman
  • Date: Mon, 3 Jun 2013 16:16:17 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none

Benn:

I would agree with Eric. I feel you have a solid proposal to move forward
with.

My only comment builds on Eric's comments addressing the single point of
failure issue. If I am understanding the proposal fully, you are dependent on
the logging from each credential store. It is probably implicit in your
proposal (and likely addressed by other parts of the IAP) but you may want to
call out explicitly that integrity checking of logging is critical. Any gaps
in logging through faults at the credential store or during a fault of
counter might invalidate all IAQ's unless the validators are taken off line
for holders of IAQ's.

Let me know if you want to discuss further.

Regards,
Mark

--------------------------------------------------
Mark Rank
Project Manager - Identity & Access Mgt
UCSF Information Technology Services (ITS)
email:

phn:414-331-1476
--------------------------------------------------

________________________________________
From:


[]
on behalf of Eric Goodman
[]
Sent: Friday, May 31, 2013 3:49 PM
To:

Subject: RE: [Assurance] Failed Authentication Counter Strawman

I like your proposal.

I hadn't realized 800-63-1 changed the requirements and their arguments
against simple counters are interesting. I think you address the first and
the last very well, I had some additional thoughts on the second one:

"The approach is a single point of failure."

In addition to the points you make countering this statement:

* If the failure is a failure to send current statistics to the central
"counter", as long as the problem doesn't persist for more than 72 hours and
you can resync the counts before the 72 hour timeframe is up, you wouldn't
need to stop asserting the IAQ.

* You can still implement rate-limiters at the individual authenticators
(i.e., limited login attempts/unit time). At the end of any such outage, if
stats from the outage period were unavailable, you could simply increment all
of your users' counters by the maximum possible attempt rate * duration of
the outage.

I can envision other attacks that would allow someone to bypass a central
counter (e.g., compromising the count database, modifying the authenticator
logs before they are written out), but those kinds of attacks are probably so
intrusive that brute force limit being exceeded is the least of your worries.

--- Eric

-----Original Message-----
From:


[mailto:]
On Behalf Of Benn Oshrin
Sent: Friday, May 31, 2013 2:52 PM
To:

Subject: [Assurance] Failed Authentication Counter Strawman

As mentioned on a couple of previous calls, I've been interested in a
solution for counting failed authentication attempts. I've drafted a
strawman, available for review at

https://spaces.internet2.edu/x/kAtOAg

I'd be interested in comments and feedback, and assuming no fatal flaw, I'd
also be interested if anyone else is considering a similar approach.

Thanks,

-Benn-




Archive powered by MHonArc 2.6.16.

Top of Page