Of Security, Privacy, and Trust

1. Of Security, Privacy, and Trust

2. Security • Personal security is largely distinct from network security (modulo VPN’s and authentication to the network) • Personal security is used to • digitally sign document, code and email • assert identity and/or attributes • encrypt email messages • authenticate web servers to users • lots of other things

3. Privacy • Privacy applies mainly to individuals and represents the user’s desire to manage the release of personal information to private and public sectors. • Privacy also applies to corporations, who want to keep not only corporate information private, but hide the business rules that are applied to decisions about customers • Privacy can only be degraded; it can not be repaired • Privacy regulations for private and public sectors are different

4. Trust • Relying parties (targets) trust security domains to assert trustworthy attributes and identities • Users trust security domains to protect their interests • Security domains trust relying parties to protect the attributes that they receive • Security domains trust their users to abide by the domain’s rules

5. Of Security, Privacy, and Trust • Is it security or is it liability? • Liability has other remedies, including disclaimers, contractual sharing of responsibilities, indemnification, etc… • Is it privacy or is it discretion? • Privacy can only be degraded. How can privacy loss be managed? Should privacy be an active or passive service? When do we want our privacy given up? • Is it trust or is it risk management (contracts)? • Our notions of trust are soft, contradictory, volatile, intuitive, and critical to how we act in the world. Contracts and current computational approaches are hard and slow to change.

6. Rethinking Privacy • Passive privacy - The current approach. A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. The user has no control, and no responsibility. And no one is happy... • Active privacy - A new approach. A user (through their security domain) can release attributes to the target that are not necessarily personally identifiable. If the attributes are personally identifiable, the user decides whether to release them. The user has control, along with commensurate responsibility. Who will be happy?

7. Rethinking Privacy • For access to controlled resources, there is a spectrum of approaches available. • At one end is the attribute-based approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy. • At the other end is the identity-based approach, where the identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. Since this leads with identity, this approach requires the target to protect privacy.

8. Business Issues and Active Privacy • When does a company want to know identity versus behavior? • How many people register software? Major appliances? • Does software support depend on the user or the attribute “know a twenty-character identifier tag on the cd case?” • When a company wants to know identity, what will it take for the user to reveal it? • Obvious business requirement • Compelling ease of use for the user • (A rubber squeeze toy) • Think of how popular cash is despite the convenience of credit

9. Identity Service Providers • Federated administration now a theme of Microsoft and Passport/Hailstorm and the Liberty Alliance Project. • If there is to be “identity service providers”, should it be a competitive marketplace or a monopoly? • If one is to trust their identity service provider, should it be a corporate or government service? Does a corporate marketplace with government controls (e.g. audits, safety checks, etc.) work? • How many identities can you handle?

10. The Architecture of Authentication • Identification/Authentication has two components • the initial determination that a particular subject should be provided a specific credential (identification). i.e. “getting a credential” • the continuing processes of that subject establishing their electronic presence (authentication) “using a credential” • Examples • two forms of photo id in person to be issued a computer account, and then Kerberos to authenticate • providing a name and social security number to receive a PIN, and being able to view student loan data with that PIN • The “strength” of authentication depends on both processes • The need for strong authentication depends on the resources that are being offered to the authenticator

11. The Architecture of Authorization • Should the authorization decision be made by the user’s domain, based on business rules provided by the target or by the target, based upon attributes provided by the user’s domain? • If at the target, should the user’s domain pass all attributes about a user to a target, to protect the privacy of the target, or a minimal set of attributes, to protect the privacy of the user? • The answers depend on point of view, scalability, manageability, and performance

12. Identity in the real world is very hard. There are some legitimate needs that need formal and high levels of security services Documents must be notarized There are cases where email be signed and encrypted Authentication is in general a “local” service that can be conveyed globally We Need A Strong Authentication Service

13. We are only beginning to understand authorization Permissions are much more volatile than identity Delegation and non-determinism are hard Privacy rests here, and we don’t understand privacy Expressions of permissions require complex data structures We Need a Flexible Interrealm Authorization Service

14. Authentication and Authorization • On occasion, a screwdriver can be used to drive nails, especially if there is not a hammer handy. • Some inter-realm authentication systems can be used for authorization (e.g. Kerberos, X.509) • Inter-realm attribute exchange can pass identifiers and thus be used for inter-realm “authentication”

15. Shibboleth Trust Model • Shibboleth/SAML Communities (aka Tribes) • Club Shib • Club Shib Application form

16. Shibboleth/SAML Communities(aka Tribes) • A group of organizations (universities, corporations, content providers, etc.) who agree to exchange attributes using the SAML/Shibboleth protocols. • In doing so they implicitly or explicitly agree to abide by common sets of rules. • The rules and functions associated with a tribe include: • A registry to process applications and administer operations • A set of best practices on associated technical issues, typically involving security and attribute management • A set of agreements or best practices on policies and business rules governing the exchange and use of attributes. • The set of attributes that are regularly exchanged (syntax and semantics). • A mechanism (WAYF) to identify a user’s security domains

17. Club Shib • The coolest tribe… also the first and only to date • Members can be organizations that are origins (IdSP’s), targets (student loan services, content providers) or both (universities, museums, etc.) • Associated functions • Registry service to be operated by I2/ Educause? But open to all.. • Best practices on authn/id’s • Best practices on the management of exchanged attributes • Attribute sets (eduPerson and eduOrg) to use to exchange attributes • WAYF done via Wayfarer service

18. Club Shib Registry service • Receives and processes applications • Operates Wayfarer (tm Jeff Hodges) • origin sites are listed • target sites can use • Insures uniqueness of key identifiers among tribal members • Houses PKI components of Shib • institutional signing keys • bridging if important

19. Club Shib Application Form • Complete origin/target Shibboleth tech info as required • Agree to be tech tribal-RFC compliant • Agree to be policy tribal-RFC compliant • Implement eduPerson and eduOrg? • Plug origins (campuses) into Wayfarer • Submitted by DNS person

20. Tech Tribal-RFC • Must/should have non-clear text local authentication, no group accounts, etc... • eduPerson and eduOrg • Is this Tech RFC a set of examples drawn from the members or a summarized best practices? • http://middleware.internet2.edu/internet2-mi-best-practices-00.html?

21. Policy Tribal-RFC • Must destroy info after use; no aggregation or re-use • Should have a policy on directory management • Must document reassignment/reuse policies of ePPN • Origins will provide “member of the community” attribute to other club members; other attributes to be exchanged negotiated on a per security domain basis. • Tribal Policy RFP level of officialness?

22. eduOrg possible attributes • URL of campus authentication practices • URL of campus policy on the reuse of ePPN and other identifiers • List of current semester course numbers