Subject: [abfab] ** OAuth Tutorial & OAuth Security Session **

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 6 Nov 2010 21:55:16 -0500

Hi all, 

please consider attending the following two meetings! 

** OAuth Security Session **

	• Date: Monday, 13:00-15:00
	• Location: IAB breakout room (Jade 2)
	• Contact: Hannes Tschofenig [email-masked]
The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a  discussion session.

As a starting point I suggest to look at the following documents:

	• http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
	• http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
	• http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt

Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you!

** OAuth Tutorial **

	• Date: Wednesday, 19:30 (after the plenary)
	• Location: IAB breakout room (Jade 2)
	• Contact: Hannes Tschofenig [email-masked]
OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, seehttp://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!)

It is helpful to read through the documents available int he working group but not required.

Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 08 Nov 2010 00:04:21 +0100

Hi all,

Mark McGloin and me have been working on OAuth 2.0 security 
considerations for a couple of weeks now. Since we both cannot attend 
the IETF-79 meetings, we would like to provide the WG with information 
regarding the current status of our work. I therefore uploaded a 
_preliminary_ version of our working document to the WG's wiki at 
http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. 
The focus of this version was on consolidating previous work as well as 
results of mailing list discussions and start working towards a rigorous 
threat model.

Please give us feedback.

regards,
Torsten.

Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
> OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 9 Nov 2010 01:54:57 +0000

I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Sunday, November 07, 2010 3:04 PM
To: Hannes Tschofenig
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] Board; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

Hi all,

Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a _preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. 
The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model.

Please give us feedback.

regards,
Torsten.

Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
> 	* Date: Monday, 13:00-15:00
> 	* Location: IAB breakout room (Jade 2)
> 	* Contact: Hannes Tschofenig [email-masked] The security 
> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a  discussion session.
>
> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
> 	* 
> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
> txt
>
> 	* Date: Wednesday, 19:30 (after the plenary)
> 	* Location: IAB breakout room (Jade 2)
> 	* Contact: Hannes Tschofenig [email-masked] OAuth allows a 
> user to grant a third-party Web site or application access to their 
> resources, without necessarily revealing their credentials, or even 
> their identity. The OAuth working group, see 
> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to 
> finalize their main specification, namely OAuth v2: 
> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>
> Based on the positive response at the last IETF meeting (in 
> Maastricht) we decided to hold another OAuth tutorial, namely on 
> *Wednesday, starting at 19:30 (after the IETF Operations and 
> Administration Plenary) till about 21:00. (Note: I had to switch the 
> day because of the social event!)
>
> Up-to-date information can be found here: 
> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>
> Ciao
> Hannes
>

---

From: [email-masked]
Date: Tue, 9 Nov 2010 08:07:56 +0000

We think the security considerations should be based on a threat model of OAuth. But a complete threat model would blow up the spec.

We therefore aim to produce a separate security document (informational I-D/RFC) covering threat model as well as security design and considerations. The security considerations section of the core spec can then be distilled from this document.

Regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Sunday, November 07, 2010 3:04 PM
To: Hannes Tschofenig
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] Board; [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

Hi all,

Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a_preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. 
The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model.

Please give us feedback.

regards,
Torsten.

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 10 Nov 2010 01:36:35 -0500

(With apologies for bringing up a tangential matter...)

Talking about the OAuth model, I still see here "Client" instead of 
"Consumer."  I thought there was an agreement on the terminology 
change.  I have no specific preference for either term, but  I think it 
is essential that our terminology be consistent, especially now that 
other SDOs are considering adopting OAuth.

This is not necessarily a question for Richard, but could someone set me 
straight: Is it "Client" or "Consumer"? 

With thanks,

Igor

Richard L. Barnes wrote:
> Of course not every scenario calls for all of the security knobs to be 
> turned to 11.  Think of things instead in terms of syllogisms: "IF you 
> want X guarantee, THEN you MUST do A, B, C."
>
> Then you can also read the same things backwards in a given deployment 
> scenario: "Given that I can't do B, I can't get assurances X, Y, but I 
> can get Z (if I do D, F as well)".
>
> I promise to produce something more concrete soon :)  In the meantime, 
> this text illustrates what I mean pretty well:
> <http://tools.ietf.org/html/draft-barnes-oauth-model-01#section-5>
>
> --Richard
>
>
> On 11/10/10 2:03 PM, Anthony Nadalin wrote:
>> Issue here is that guarantees (and what you want as a guarantee may 
>> not be what somebody else wants) can vary depending on scenario and 
>> deployment.
>>
>> From: Richard L. Barnes [mailto:[email-masked]]
>> Sent: Tuesday, November 09, 2010 12:54 AM
>> To: [email-masked]
>> Cc: Anthony Nadalin; Tschofenig, Hannes; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked] Board; [email-masked]; 
>> [email-masked]
>> Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial&  OAuth Security 
>> Session **
>>
>> I would say that the security considerations should be based on a 
>> model of OAuth.  Start with a model of the protocol and the 
>> guarantees you want, then explain how to use security mechanisms to 
>> achieve those guarantees.
>>
>> I promised Hannes today to do a review of the current document (which 
>> I admit I haven't read) and start on some security considerations 
>> from that perspective.  So expect that in the next few weeks.
>>
>> --Richard
>>
>>
>>
>>
>> On 11/9/10 4:07 PM, [email-masked] wrote:
>>> We think the security considerations should be based on a threat 
>>> model of OAuth. But a complete threat model would blow up the spec.
>>>
>>> We therefore aim to produce a separate security document 
>>> (informational I-D/RFC) covering threat model as well as security 
>>> design and considerations. The security considerations section of 
>>> the core spec can then be distilled from this document.
>>>
>>> Regards,
>>> Torsten.
>>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>>
>>> From: Anthony Nadalin<[email-masked]>
>>> Cc: [email-masked]<[email-masked]>; [email-masked]<[email-masked]>;
>>> [email-masked]<[email-masked]>; [email-masked]<[email-masked]>;
>>> [email-masked]<[email-masked]>; [email-masked]<[email-masked]>;
>>> [email-masked]<[email-masked]>; [email-masked] Board<[email-masked]>;
>>> [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
>>> Subject: RE: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>>
>>> I was looking for less of an analysis and more of considerations (of 
>>> the current flows and actors), I'm not sure how to adapt what you 
>>> have done to actually fit in the current specification, was your 
>>> thought that you would produce a separate security analysis document?
>>>
>>> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked]; [email-masked] Board;
>>> [email-masked]; [email-masked]
>>> Subject: Re: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>>
>>> Hi all,
>>>
>>> considerations for a couple of weeks now. Since we both cannot 
>>> attend the IETF-79 meetings, we would like to provide the WG with 
>>> information regarding the current status of our work. I therefore 
>>> uploaded a_preliminary_ version of our working document to the WG's 
>>> wiki at 
>>> The focus of this version was on consolidating previous work as well 
>>> as results of mailing list discussions and start working towards a 
>>> rigorous threat model.
>>>
>>> Please give us feedback.
>>>
>>> regards,
>>> Torsten.
>>>
>>>> consideration section of OAuth 2.0 (draft -10) is still empty. 
>>>> Hence, we would like to put some time aside to discuss what 
>>>> security threats, requirements, and countermeasures need to be 
>>>> described. We will use the Monday, November 8, 1300-1500 slot to 
>>>> have a  discussion session.
>>>>
>>>> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
>>>>     * Contact: Hannes Tschofenig [email-masked] OAuth 
>>>> allows
>>>> a user to grant a third-party Web site or application access to their
>>> secdir mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/secdir
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 09 Nov 2010 16:53:40 +0800

I would say that the security considerations should be based on a model 
of OAuth.  Start with a model of the protocol and the guarantees you 
want, then explain how to use security mechanisms to achieve those 
guarantees.

I promised Hannes today to do a review of the current document (which I 
admit I haven't read) and start on some security considerations from 
that perspective.  So expect that in the next few weeks.

--Richard

---

From: Mark Mcgloin <[email-masked]>
Date: Tue, 9 Nov 2010 14:54:06 +0000

When Torsten and I started pulling together the security considerations
over the last 4-6 weeks, we toyed with the idea of either populating the
security considerations section of the protocol with a list/tree of
considerations, or creating a more comprehensive document to ensure we
covered all aspects, list security features and which would also act as a
security aid to developers implementing the oauth protocol. We decided on
the latter and agreed it could later be distilled down to something that
will fit into the security considerations section of the protocol.

Bear in mind the document needs tidying but we wanted to push something in
before the security meeting in China

Regards
Mark McGloin

[email-masked] wrote on 09/11/2010 08:53:40:

> "Richard L. Barnes" <[email-masked]>
> Sent by: [email-masked]
>
> 09/11/2010 08:53
>
> To
>
> [email-masked]
>
> cc
>
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked] Board" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "Tschofenig, Hannes"
> <[email-masked]>, "[email-masked]" <[email-masked]>
>
> Subject
>
> Re: [OAUTH-WG] [secdir] ** OAuth Tutorial & OAuth Security Session **
>
> > I was looking for less of an analysis and more of considerations
> (of the current flows and actors), I'm not sure how to adapt what
> you have done to actually fit in the current specification, was your
> uploaded a_preliminary_ version of our working document to the WG's wiki
at
> http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/
> SecurityConsiderations/oauth20_seccons_20101107.pdf.
> > The focus of this version was on consolidating previous work as
> well as results of mailing list discussions and start working
> towards a rigorous threat model.
> >
> > Please give us feedback.
> >
> > regards,
> > Torsten.
> >
> Hence, we would like to put some time aside to discuss what security
> threats, requirements, and countermeasures need to be described. We
> will use the Monday, November 8, 1300-1500 slot to have a  discussion
session.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 10 Nov 2010 06:03:47 +0000

Issue here is that guarantees (and what you want as a guarantee may not be what somebody else wants) can vary depending on scenario and deployment.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2010 12:54 AM
To: [email-masked]
Cc: Anthony Nadalin; Tschofenig, Hannes; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked] Board; [email-masked]; [email-masked]
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

I would say that the security considerations should be based on a model of OAuth.  Start with a model of the protocol and the guarantees you want, then explain how to use security mechanisms to achieve those guarantees.

I promised Hannes today to do a review of the current document (which I admit I haven't read) and start on some security considerations from that perspective.  So expect that in the next few weeks.

--Richard

On 11/9/10 4:07 PM, [email-masked] wrote:
>> 	* Contact: Hannes Tschofenig [email-masked] OAuth allows

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 10 Nov 2010 14:19:47 +0800

--Richard

On 11/10/10 2:03 PM, Anthony Nadalin wrote:
> Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Nov 2010 01:00:37 -0600

[That is some cc list!  Do you really need a cc list that large for this
thread?  I've set the reply-to to just [email-masked] (note: I'm NOT
subscribed to that list).  Please honor the reply-to header.  It's a
good idea to set reply-to when making announcements, so that replies
don't flood people who are almost certainly not interested.]

On Tue, Nov 09, 2010 at 08:07:56AM +0000, [email-masked] wrote:
> We think the security considerations should be based on a threat model
> of OAuth. But a complete threat model would blow up the spec.

Really?  I would think that a threat model for OAuth could be described
fairly briefly.  What is the typical value of resources protected by
OAuth?  What kinds of attackers (active, passive, ...) does OAuth aim to
defeat, and under what assumptions (end-points are secure, trusted third
parties are trustworthy, certain cryptographic algorithms are not broken
with parameters in certain ranges, smartcards are secure, ...)?  Which
kinds of attacks does OAuth explicitly not protect against (e.g., DoS)?
What resources do you expect attackers to apply to compromising
resources protected by OAuth?

A few pages should do for the threat model.  An abstract of the OAuth
threat model should also be possible to write.

> design and considerations. The security considerations section of the
> core spec can then be distilled from this document.

Sure.  Procedurally speaking, that works.

Nico
--