Of Security, Privacy, and Trust. Security Personal security is largely distinct from network security (modulo VPN’s and authentication to the network)

Of Security, Privacy, and Trust

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

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

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

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.

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?

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.

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

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?

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

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

We Need A Strong Authentication Service

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 Flexible Interrealm Authorization Service

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

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”

Shibboleth Trust Model

Shibboleth/SAML Communities (aka Tribes)

Club Shib

Club Shib Application form

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

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

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

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

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?

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?

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