Human-readable summary of Issue 239 and the current proposed solution
Hi all, I took an action item last week to summarize issue 239 in a human readable format. Here it is: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com
Excellent work. Thank you. Sincerely, John Wunderlich (@PrivacyCDN) <http://privacybydesign.ca/> <http://privacybydesign.ca/> <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>
On Feb 18, 2016, at 00:02, Sarah Squire <sarah@engageidentity.com> wrote:
Hi all,
I took an action item last week to summarize issue 239 in a human readable format. Here it is:
Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo.
In order to get Bob access to the photo, three steps are completed:
Bob begins his transaction by requesting the photo Bob identifies himself within the context of his transaction The authorization server grants access to the photo within the context of his transaction
Eve would like to access the photo as well. She completes the following steps:
Eve begins the transaction by requesting the photo Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction The authorization server grants access to the photo within the context of her transaction
Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate.
The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted.
We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end.
Sarah Squire Engage Identity http://engageidentity.com <http://engageidentity.com/>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Ditto. Thanks, Sarah! I'll create a wiki page for this new "auxiliary doc". (What do we think of adding sections to briefly explain the other mitigation options and why each didn't make the cut? Could save us a lot of explaining time down the road.) Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Feb 19, 2016, at 6:47 AM, John Wunderlich <john@wunderlich.ca> wrote:
Excellent work. Thank you.
Sincerely, John Wunderlich (@PrivacyCDN)
<PastedGraphic-4.tiff>
Privacist & PbD Ambassador
On Feb 18, 2016, at 00:02, Sarah Squire <sarah@engageidentity.com> wrote:
Hi all,
I took an action item last week to summarize issue 239 in a human readable format. Here it is:
Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo.
In order to get Bob access to the photo, three steps are completed:
Bob begins his transaction by requesting the photo Bob identifies himself within the context of his transaction The authorization server grants access to the photo within the context of his transaction
Eve would like to access the photo as well. She completes the following steps:
Eve begins the transaction by requesting the photo Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction The authorization server grants access to the photo within the context of her transaction
Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate.
The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted.
We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end.
Sarah Squire Engage Identity http://engageidentity.com _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. <signature.asc> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (3)
-
Eve Maler -
John Wunderlich -
Sarah Squire