Assurance

[David Bantz <>]

Mark, thanks for the link to the OMB doc; I hadn't seen this description of LoAs.  I particularly like Table 1 (imaged below for others' convenience). 

There are reasons persuasive to me to aim for credential management meeting assurance profile for LoA2/ Silver.  I've been making them intramurally for years.  But those reasons are not persuasive to many others.  When I first broached LoA based on NIST 800-63 and quoted the narrative for the level that matched our existing password entropy (LoA 1 - adequate only for bookmarks or preferences in the NIST formulation) and suggested password entropy meeting LoA2, I was roundly condemned as an ivory tower theorist with no understanding of real world needs, for which 6 character passwords (never mind dictionary checks or expiration) were adequately robust.   We've made progress - in good part due to the valuable work of many on this list - but I still need to make a case for any change that is seen as making access more difficult or generating more help desk calls.  While we enforce stronger passwords now, the enforcement is arguably not uniformly at LoA2 (14 bits of entropy), and there is only modest concern with authentication via password relay to or password synchronization with external hosted services.  To be fair to the skeptics at my institution, our help desks and other support points do routinely receive complaints about password complexity, password expiration, and vetting questions for self-service reset of forgotten passwords.  So a clear and persuasive case has to made for changes that improve the level of assurance and protection from identity theft that are perceived  - rightly or wrongly - as creating unnecessary barriers to services.

David Bantz

On Thu, 15 Mar 2012, at 11:49 , Jones, Mark B wrote:

“InCommon Bronze and Silver are intended to be compatible with US federal government Identity, Credential, and Access Management (ICAM) Trust Framework Provider Adoption Process (TFPAP) Levels of Assurance 1 and 2.”

http://www.incommon.org/docs/assurance/IAP_V1.1.pdf

 

The ICAM (http://www.idmanagement.gov/pages.cfm/page/ICAM) Levels of Assurance are based on OMB M-04-04 E-Authentication Guidance which describes level 1 and 2 as:

 

Level 1: Little or no confidence in the asserted identity’s validity.

Level 2: Some confidence in the asserted identity’s validity.

 

If your institution’s existing password credential is being managed at less than level 2 (meaning you are at level 1) and is being used to access student systems (FERPA), employee systems (PII), financial systems, or patient care systems (PHI), then I submit that there are plenty of justifications other than InCommon Silver qualification to overhaul your password credential management.

 

If you are of the mind that “Some confidence in the asserted identity’s validity” is not sufficient then we should not be talking about modifying Silver (which is based on a well defined standard) but instead talking about an InCommon Gold profile that would be based on OMB Level 3.

 

From:  [mailto:] On Behalf Of David Bantz
Sent: Thursday, March 15, 2012 1:44 PM
To: 
Subject: Re: [Assurance] silver and two-factor ...

 

If an institution's existing password credential management can be tweaked to meet requirements of an assurance profile (say because you already require high-entropy passwords and encrypt both store and communication of passwords) I can see how the institution justifies this effort as meeting best practices, future-proofing, and providing potential services to researchers.

 

If an institution's existing password credential management would require substantial revision - say policy changes that impact existing services or user experience - how does the institution justify the effort & cost required for those changes?  The immediate benefits appear to be limited to researchers who may require Silver LoA for some NSF or NIH services, but that's a small population on most campuses.   Are considerations like adopting best practices or increasing assurance qualitatively adequate to justify what may be seen as costly inconveniences by many users?  Or does the apparent high cost/benefit driving institutions toward adopting certificate or OTP ("two factor authN") for the small population of users initially benefitting from Silver LoA?

 

Perhaps another way of asking this question is, if you had your wish, would you make your IAM infrastructure generally Silver LoA rather than adopting OTP or certificate-based authN for a subset of users to enable them to use services requiring Silver LoA?

 

David Bantz

 

 

On Thu, 15 Mar 2012, at 10:12 , Roy, Nicholas S wrote:

Thanks David,

 

“I suggest considering cloning your existing username/password technology, probably with the same usernames but different passwords, managing it in a way that makes you feel comfortable with its Silver-ness.”

 

That’s a solution we’ve considered, but we are trying to “eat our own dog food” when it comes to using a single central campus authentication service for passwords.  If we did that it would be setting a precedent that I don’t think we want to set.  There is also the risk (and high likelihood, from other such behavior we’ve observed) that people would manually sync passwords between the two systems.

 

Using a solution like OTP tokens or personal certs is valuable in that it is a completely different type of authentication mechanism, which can be said to provide a benefit for campus beyond the existing username/password system.  It’s then an easier job of selling a new service like that, when we can say that it will benefit lots of other applications around campus that could use the service for enhanced security.  Rooting the registration process for Silver in the issuance of a token or enrollment of a certificate on something like a smart card or secure USB fob also provides a lot of advantages when trying to create the registration process necessary for Silver.

 

Nick

 

From:  [mailto:] On Behalf Of David Walker
Sent: Wednesday, March 14, 2012 1:01 PM
To: 
Subject: RE: [Assurance] silver and two-factor ...

 

I think there are two issues here:

• First, is the existing authentication service good enough for Silver?
• Second, if the answer to the first question is no, what should be done?

I think for many institutions that the answer to the first question would be something like "Well, it would be, but we have a number of the issues Nick mentioned."  That brings us to the second question.

Adding a second factor is one way to address the second question, particularly if you're already using second-factor technology.  If you're not already using that second authentication technology, though, it can be expensive.

I suggest considering cloning your existing username/password technology, probably with the same usernames but different passwords, managing it in a way that makes you feel comfortable with its Silver-ness.  I recognize that many institutions want to implement 2-factor authentication anyway, and that's fine, but the requirements for federal LoA-2 (and, therefore, Silver) are satisfied without it, so this could be a less expansive path for many institutions.

David Walker

On Wed, 2012-03-14 at 17:16 +0000, Roy, Nicholas S wrote:

A question I have is what kind of authentication services are schools running who feel that they can use passwords to achieve Silver? Specifically, what is your central source of authentication? What will end up providing the verifier role to your Silver-compliant IdP? What kind of clients of this service do you have (ERPs, *.webapp, workstations (Windows, OS X, Linux, other?), printers, file servers, network appliances, etc.) How tightly controlled is access to the service? What kinds of authentication endpoints are available (LDAP, LDAPS, Kerberos, RADIUS, web services, etc.) how are those endpoints protected and from what network scope can clients connect to them (only on-campus, off campus, only via a VPN, other?) Do you provision passwords to other authentication services that aren't your central provider? How do you plan to assess and/or enforce client behavior (for example, use of SSL for web forms that validate passwords against your authentication service), or do you consider that out of scope?

I'm not saying you can't use passwords to achieve Silver, but the project complexity seems pretty high in a big, heterogeneous campus environment.

Nick

-----Original Message-----
From:  [] On Behalf Of Steven Carmody
Sent: Tuesday, March 13, 2012 11:48 AM
To: 
Subject: [Assurance] silver and two-factor ...

I'm wondering why so many sites that are interested in Silver are so 
interested in two-factor....

I haven't looked at the Silver profile in a long time. But, my memory is 
that strong passwords, stored sufficiently securely, and not replicated 
into uncontrolled environments (eg google), would pass muster with 
Silver. I'm assuming, of course, that the other Silver criteria (eg 
around identity proofing, account claiming, etc) would also be met.

I can imagine that there may be issues with those passwords passing 
through a variety of systems (eg systems that are then authenticating 
users against a central ldap, for instance). But, that's just a guess -- 
I would be interested in hearing about specific concerns that are 
driving sites toward two-factor.

Thanks for any light you can shine on this!