Below is another extended text summarizing the talks from the second and last day of the Summit. Some interesting stuff here, to be sure. Unfortunately I was compelled to sign an NDA before the most interesting talk of all, so my notes from that one are not included. It may come later if I remember in a few months.
I took home a somewhat surprising impression of many of the Microsoft employees presenting the material. They seemed unabashedly humble at times, saying things like “We really don’t have any idea what the best way to do this is.” It was almost as though they were admitting that they’re learning how to write operating systems as they go. Perhaps that’s why Longhorn’s release is still so far out on the horizon. Anyway, I found this candidness oddly charming and really appreciated it.
Web Services Security
- Authentication needs to cross boundaries between organizations
- Problems: IT overhead, more logins/passwords for end user
- Federated identity management to the rescue
- Allows each organization to act as an authority for managed identities
- Choose trusts and levels of trusts between organizations
- Concepts
- Authorities manage claims (identity, access permissions, accept claims from outside)
- Principles interact via claims (user roles, application roles)
- Trust relationships limit scope of claims
- Trust brokers provide edge services (centrally manage trusts, audit)
- Tokens define identities
- Policies describe tokens required and how to get them
- ADFS based on WS-Federation; extends Active Directory to the internet
- Manage roles, groups, tasks in Authorization Manager
X.509 Certificate Support
- Limited support in .NET v1.0-1.1 other than basic field decoding
- Whidbey adds decoding for additional certificate types, and certificate management
- Supports custom extensions
- Each user may have a personal certificate store object
- Includes API
- New classes to support W3C-compliant XML encryption
- Encrypt/decrypt signed XML document using X.509 certificate
- Whidbey beta has been released at TechEd 2004; final release early 2005
Building Secure Applications in Longhorn
- LUA = Least priviledged user account
- Run an app or service with only enough priviledges to get the job done and no more
- Apps for regular users must be written to run as non-admin user
- Example of poor coding is Windows calculator which saves settings into win.ini
- Application verifier uses shim to redirect writes to non-admin user’s own profile
- Problem points are spyware, legacy apps, common OS config tasks, user mistakes
- Simple scenarios like VPN require admin rights
- Goal: with LUA the user experience should be just the same as today
- Enable apps to install/run/update/uninstall, all without user admin rights
- When a user needs to run an admin app this should happen in “isolated” sessions
- Applications could fail if run isolated; MS may use WU to distribute shims to address
- 95% of apps expected to work
- Let users know when they are about to do something potentially unsafe
- Hopefully MS will be able to educate users and help them make good decisions
- Step 1 = fix the OS
- Not easy to fix; users have been running as admin since Win95
- Per-user ActiveX controls and file extensions
- File system and registry will be virtualized for users
- Simple Secure Consent UI is independent, not allowing any scripting, etc.
- Three desktop control config options
- Ability to allow only applications from certain publishers to and install or run
- For unknown publishers, prompt (default for home users)
- XP compatibility mode does not check trusts (not suggested)
- Depends on signing authority for validation
- Caching since this process must take place very quickly
- Same as current publisher trust system
- Driver store
- Repository of drivers populated into driver store on local machine
- Only administrators can populate, but once added, anyone can install and use them
- Longhorn will require all drivers to be signed
- Admins (and possibly users in some circumstances) can force installs
- Code validation happens for every app at each run; checksums stored in local database
- Possible feedback mechanism to accept user input regarding application behavior
- Will mitigate most virus/worm attacks although priviledge elevations not impossible
- Worst-case scenario might be loss of user data
- Conducting extensive usability studies during Longhorn development
PKI Walkthrough
- PKI goal is to improve security on network and for authentication
- Most value in wireless (802.1x with keys), internal SSL, VPN
- No or few changes in user behavior required
- Certificate authority servers must be extremely well-secured
- Write a certificate policy
- Positive identification of CA (name, location, IP, etc.)
- How are certificates issued, renewed and revoked
- Procedures for users, IT, HR
- Architecture example: root CA (offline), intermediate CAs (offline), issuing CAs
- Includes third-party root CA as well as Microsoft
- Cannot change CA type later
- Externally-used certificates should not reveal any PKI or network infrastructure
- HTTP points rather than LDAP
- Operations: hardware, software (OS and patches), disaster planning
- In Domain Security Policy, go to Windows -> Security -> Key Policies, and import
- See MS KB article Q295663
- Grab root certificate from floppy disk, since root CA is offline
- Include certificate in GPO for end users
- “Lock workstation” is recommended smart card removal behavior
- Sign outgoing mail rather than encrypting it, unless this is okay at destination
- Best practices for EFS: see MS KB article Q223316
- Can manually maintain NTAuth certificate store with CERTUTIL.EXE