Assurance

["Rank, Mark" <>]

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-