assurance - RE: [Assurance] silver and two-factor ...
Subject: Assurance
List archive
- From: "Roy, Nicholas S" <>
- To: "" <>, "Jones, Mark B" <>
- Subject: RE: [Assurance] silver and two-factor ...
- Date: Thu, 15 Mar 2012 20:22:05 +0000
- Accept-language: en-US
It’s the helpdesk calls and issues with user education around certificate enrollment and management that make me lean toward OTP devices. You never have to
remember anything other than a four or five digit PIN, and the rest of the secret is provided for you by a key fob that you. Nick From: [mailto:]
On Behalf Of 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.” 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:
On Behalf Of David Bantz 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: On
Behalf Of David Walker I think there are two issues here:
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? |
- RE: [Assurance] silver and two-factor ..., (continued)
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/13/2012
- Re: [Assurance] silver and two-factor ..., Tom Scavo, 03/13/2012
- RE: [Assurance] silver and two-factor ..., Farmer, Jacob, 03/13/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/14/2012
- RE: [Assurance] silver and two-factor ..., David Walker, 03/14/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/15/2012
- Re: [Assurance] silver and two-factor ..., David Bantz, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/15/2012
- Re: [Assurance] silver and two-factor ..., David Bantz, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/15/2012
- Re: [Assurance] silver and two-factor ..., Tom Scavo, 03/15/2012
- Re: [Assurance] silver and two-factor ..., Tom Scavo, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/16/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/16/2012
- Re: [Assurance] silver and two-factor ..., Tom Scavo, 03/16/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/16/2012
- Re: [Assurance] silver and two-factor ..., David Bantz, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Dunker, Mary, 03/16/2012
- Re: [Assurance] silver and two-factor ..., Tom Scavo, 03/16/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/16/2012
- Re: [Assurance] silver and two-factor ..., David Bantz, 03/15/2012
- RE: [Assurance] silver and two-factor ..., Roy, Nicholas S, 03/15/2012
- RE: [Assurance] silver and two-factor ..., David Walker, 03/14/2012
- RE: [Assurance] silver and two-factor ..., Jones, Mark B, 03/13/2012
Archive powered by MHonArc 2.6.16.