Human-to Human Delegation Issues in Open World

Session Topic: Human-to-Human Delegation Issues in Open World

Wednesday 1G

Convener: Hidehito Gomi

Notes-taker(s): Amanda Anganes

Tags for the session - technology discussed/ideas considered: Delegation, human interaction, OAuth 2

FitBit, NIKE air band, personal information tracking – data is viewable on your smart device and also shareable

Human-Human – directly sharing information with other people

This is more often accomplished in the real world via human-software (or software- software) interaction (unless you email someone an access token)

OAuth example on the board – Alice stores her data (including personal health records) on a server, using an OAuth token; application can access the data using another Access Token

What happens when Bob wants access (and Alice wants to give it)?

Bob talks to the application; connection between Alice and Bob is not tight. This is possible using OAuth 2.0 flows / UMA where Alice can grant access to Bob so he can get a properly scoped Access Token to access the data.

Enter Carol, malicious. She tries to intercept token from Bob – if it is a true bearer token, then she can use the token maliciously to get the data.

Solutions – SSL everywhere (can use Bearer tokens), or stronger signed tokens (such as SAML assertions).

Open World – no pre-arranged agreements, Bob may not necessarily have an account on the same IdP that Alice is using. We don’t want to assume a full PKI environment.

If you can assume SSL everywhere then Bearer tokens may be OK in this scenario.

Hidehito’s proposed solution – we need delagatee authentication But how to do this with non-connected IdPs?

• Identity federation? Doesn’t quite fit with Open World assumption.
• Or, Alice puts in a rule that says Bob, authenticated at IdP2, is allowed to access her data as long as he can prove that he is Bob at Idp2.
  • This requires some amount of channel/message security
  • Cryptographic notion of the “1 free round/message”
  • PIN transfer, secret exchange, etc

If you can do a secure secret exchange, can use same client secret from both Bob & Alice. Still have the problem of getting the secret to Bob over a secure channel, and man-in-the-middle attack.

Hidehito – what about some kind of “context”, such as geolocation

• This is easily forged, VPN tunnels into particular locations

We need a formal definition of the problem – security framework, assumptions, use case, threat model – then we could talk about proper mitigations of attacks.

Action item – if Hidehito can contribute to notes his description of

• Goals
• Assumptions
• Network model (what is open, what is not)
• Threat Model

Then we could continue conversation further

For example, it matters who Carol is and what she knows/how she is attempting to attack & intercept the personal health records.

Can we assume that it would be OK to transfer “1 free message”? Once a secret is established, we can establish a secure channel.

Alan Karp from HP showing a demo of person-to-person sharing; “Home Page for Sharing”

• Family with data for each person
• Lisa can share data with other family members, see what she has shared
• Home page is protected with URL containing unguessable random home page URL, + SHA of Lisa’s key. Not OAuth based but could use OAuth tokens. Based on WaterKen. Waterken server guarantees no failures, everything is processed exactly once.
• Things on the desktop environment can be arranged in 2-dimensions; not hierarchical. Claim that humans have evolved to handle 2D nav well, but not hierarchical. Interface is a proof-of-concept (good interaction design, not UI).