Assurance

["Roy, Nicholas S" <>]

This is an area where an institutional policy requirement that clients not 
cache passwords or if they do, they cache them in a reasonably secure way 
might be the best that a lot of places can do.  While credential caches on 
clients may be in-scope, in the higher ed space, there is probably not a 
reasonable way to force a specific behavior or restrict to just certain types 
of clients without creating problems for customers.  For example, how many 
institutions now have a huge diversity of mobile devices connecting to their 
wireless network and e-mail systems?  Probably most if not all.  If you 
already have this heterogeneous client base, how realistic would it be to 
require specific types of devices connect to  these systems?  You'd have a 
lot of upset customers on your hands if you did this via enforced policy 
rather than documented policy.  The question then becomes one of user 
education: how do you tell people that their ancient Android phone caches 
passwords in a plain text file but their brand new iPhone caches them in an 
encrypted store?  How do you get them to comply?  Do you offer them subsidies 
to upgrade to a new device?  That's kind of going down a slippery slope, but 
it's illustrative of the problem.  You also have to be concerned about SPs 
that use the ECP profile, and probably have to have a contract with them that 
covers their handling of the password as it transits their service.  An 
example of that would be outsourced e-mail that uses the ECP profile to allow 
smartphones to access mail using a federated identity.

I think client management or lack thereof is probably one of the biggest 
problems in this space, and again it's not one that's Active Directory 
specific.  This is a problem for any system that uses password-based 
credentials for Silver assertions.  It's also a problem for personal 
certificate-based authentication for Silver- if a mobile device or 
workstation is compromised, and you have your personal cert on it, even if 
it's protected with a PIN, that's arguably pretty easy to crack and is then 
completely compromised.

Nick

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

 
[mailto:]
 On Behalf Of Eric Goodman
Sent: Thursday, September 08, 2011 1:59 PM
To: 

Subject: Re: [Assurance] Has anyone looked at using InCommon Silver accounts 
to access a secured wireless network?

In general, higher ed (and certainly our institution) doesn't have any good 
way to ensure that all machines are configured to not cache. (And you'd need 
to enforce/audit it on Windows, Mac, Linux, Android, iPhone, etc...)

We basically require any application to show how it will keep the clients 
from caching the credentials before granting access to the password. Some of 
our wireless/VPN services have been able to meet this requirement (e.g., 
client credential caching is controlled or influenced by a server-side 
setting, or other mitigations), and some have not. We have a "lower security" 
password that we sometimes make available to apps that are not able to meet 
this requirement.

--- Eric

On Sep 8, 2011, at 9:58 AM, Cynthia Haselton wrote:
> There are methods for limiting the cache for Windows clients...specifically 
> the cache maintained by the operating system.
> For more information on client credential caching, see this article 
> (2003/XP): http://support.microsoft.com/kb/913485
> 
> 
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Cantor, Scott
> Sent: Thursday, September 08, 2011 9:17 AM
> To: 
> 
> Cc: Russell Yount
> Subject: Re: [Assurance] Has anyone looked at using InCommon Silver 
> accounts to access a secured wireless network?
> 
> On 9/8/11 10:12 AM, "Russell J Yount" 
> <>
>  wrote:
> 
>> The Windows, Mac, and Linux wireless clients are storing the user¹s 
>> password so the wireless client may roam and re-authenticate.  Is 
>> this acceptable in InCommon Silver?
> 
> The cookbook mentions that the issue of clients caching passwords pushes 
> all of the security requirements for password storage that apply to the AD 
> server onto the client.
> 
> -- Scott
> 

Eric Goodman
Identity Management Project
UC Santa Cruz