Fundamentals: Security, Privacy, Trust

Scenarios we’d like to see...

Use of licensed library materials regardless of student’s location

Signed email

Stronger, more secure authentication procedures where needed

Encrypting of documents and email as appropriate

Fewer accounts/passwords per user

Authentication of individuals for desktop videoconferencing, chat, other collaboration tools

Inter-institutional courses sharing web sites without additional user or faculty overhead

Portals acting on our behalf

Digital signatures and work flow

Access based on roles instead of hard-coding in user names

And more….

Key Concepts

Security - protecting servers, communications, networks, hosts, personal information; has distinct authentication and authorization needs

Privacy – moving from passive privacy to active privacy

Trust - the continuum of trust and how communities use trust models

Identity Service Providers – to broker external uses of authentication and authorization, respecting security and privacy, in an appropriate trust fabric

Authentication and Authorization

architectures

technologies

Security

of networks (denial of service, physical infrastructure)

of hosts (OS bugs, mis-settings, etc.)

of personal information and communication (signed and encrypted email, directory protection, etc,)

some technologies (PKI, firewalls, etc.) can serve several areas

Key security issues

cost/benefit ratio in money

cost/benefit ratio in functionality

the human factors• complexity and ease of use

• mobility

• multiple systems and contexts

• think globally, act inconsistently

Rethinking Privacy

As Bob Blakely says, “It’s not about privacy, it’s about discretion.”

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. And no one is happy...

Active privacy - A new approach. A user (through their security domain) can pass attributes to the target that are not necessarily personally identifiable. If they are personally identifiable, the user decides whether to release them. Who will be happy?

Rethinking Privacy

For access to controlled resources, there is a spectrum of approaches available.

At one end is authorization approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach supports privacy.

At the other end is the authentication 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? • Does software support depend on the user or the attribute “have a

registered copy of the software?”

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

The Continuum of Trust

Collaborative trust at one end…• can I videoconference with you?• you can look at my calendar• You can join this computer science workgroup and edit this

computing code • Students in course Physics 201 @ Brown can access this on-line

sensor• Members of the UWash community can access this licensed

resource

Legal trust at the other end…• Sign this document, and guarantee that what was signed was what

I saw• Encrypt this file and save it• Identifiy yourself to this high security area

Dimensions of the Trust Continuum

Collaborative trust

handshake

consequences of breaking trust more political (ostracism, shame, etc.)

fluid (additions and deletions frequent)

shorter term

structures tend to clubs and federations

privacy issues more user-based

Legal trust

contractual

consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.)

more static (legal process time frames)

longer term (justify the overhead)

tends to hierarchies and bridges

privacy issues more laws and rules

Interrealm Trust Structures

Federated administration• basic bilateral (origins and targets in web services)

• complex bilateral (videoconferencing with external MCU’s, digital rights management with external rights holders)

• multilateral

• virtual organizations and Grids

Hierarchies• may assert stronger or more formal trust

• requires bridges and policy mappings to connect hierarchies

• appear larger scale

Simple point-to-point model

client

EnterpriseLDAP

directory

Attributeauthority

AuthenticationService target

Attributerequestor

Policvdecision

point

Policyenforcement

pointPolicy

enforcementpoint

Policyenforcement

points

Video directory

Service discoveryservice

Protocols

Griddirectory Video

directory

EnterpriseLDAP

directory

Trust in Transactions

In a business transaction

The user trusts the origin to faithfully represent its attributes to targets and obey privacy rules

The origin trusts the user to obey its authentication and authorization rules

The target trusts the origin to accurately manage and communicate user attributes and respect the user’s privacy settings

The origin trusts the target to take the appropriate transaction actions and to not misuse the user’s information.

The Trust Continuum, Applications and their Users

Applications and their user community must decide where their requirements fit on the trust continuum

Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach.

Many applications fit somewhere in the middle and the user communities (them that trust each other) need to select a approach that works for them.

Mapping the issues:(a slide for Annie…)

Collaborative Trust Legal Trust

Security

Privacy

Identity Service Providers

An emergent service need

Serves as an electronic broker for users to other service providers (content providers, web servers, calendar services, e-commerce, etc,)

Protects users, their resources and their privacy

Typical folks will have a handful: work, home, private

Potential suppliers are: businesses (either in-house or out-source), desktop operating systems (Microsoft), ISP’s (AOL), banks, other...

Authentication and Authorization

Authentication

Authorization

the sources of confusion

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

Layclergy Rules of Thumb

X.509 for strong authentication/legal trust

SAML/Shibboleth for flexible authorization/collaborative trust

Note that• X.509 can be used for authorization

• SAML/Shibboleth can exchange that someone was authenticated

• Neither is necessarily wise but neither is unavoidable