Subject: Re: [oauth] OAUTH Charter Proposal

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Feb 2009 09:00:39 +0200

Hi Chris, 

First, small typo: "OAuth consist of:" should be "OAuth consists of:"

[hannes] Thanks. Fixed.

Second, w/r/t to this:

	Furthermore, Oauth 1.0 defines three signature methods used to
protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group
will work on new signature methods in case the existing mechanisms do
not fulfill the security requirements. 

Where are the "security requirements" coming from? Are these defined
separately? Whose are they?

[hannes] I think a pragmatic approach is sensible here: a document that
describes a new mechanism might want to say what requirements guided the
solution and thereby provide some motivation.  

I was not thinking of an independent requirements document. I don't
think that it is well spent time. 

Ciao
Hannes

Chris 

_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: James Aylett <[email-masked]>
Date: Mon, 2 Feb 2009 08:19:39 +0000

On Mon, Feb 02, 2009 at 09:00:39AM +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> > > protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The
> > > group will work on new signature methods in case the existing
> > > mechanisms do not fulfill the security requirements.
> 
> I think a pragmatic approach is sensible here: a document that
> describes a new mechanism might want to say what requirements guided
> the solution and thereby provide some motivation.

I assumed that this would cover normal security review as per IETF
process: any and all valid security concerns raised by the community
in the process of writing or reviewing the security considerations
section, or the use of security elements in other parts of the
document. The latter is more likely to be the area where algorithm
choices may be challenged on the basis of insufficient strength or
suitability.

James

-- 
  James Aylett

  talktorex.co.uk - xapian.org - uncertaintydivision.org
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Chris Messina <[email-masked]>
Date: Mon, 2 Feb 2009 00:24:15 -0800

> think that it is well spent time.

I agree.

Maybe it was just the wording -- it sounded like there were some definitive
"security requirements" (or else you wouldn't be able to tell if they were
fulfilled!) but perhaps that's not what's intended there.

I think I understand now: if you propose new security methods or signing
mechanisms, the document will describe why to use them in situations with
different security requirements. Ok.

Thanks,

Chris

-- 
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Feb 2009 10:37:44 +0200

What about the following text: 

"
Furthermore, OAuth 1.0 defines three signature methods used to protect
requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work
on new signature methods and will describe the environments where
additional security requirements justify their usage. Existing signature
methods will not be modified but may be dropped as part of the backwards
compatible profiling activity.
"

Ciao
Hannes

PS: There are lots of people out there who have a strong opinion about
different algorithms and usage modes. I wouldn't be surprised to spend
some time discussing different algorithms. 

________________________________

	From: ext Chris Messina [mailto:[email-masked]] 
	Sent: 02 February, 2009 10:24
	To: Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: [email-masked]
	Subject: Re: [oauth] OAUTH Charter Proposal

	On Sun, Feb 1, 2009 at 11:00 PM, Tschofenig, Hannes (NSN -
FI/Espoo) <[email-masked]> wrote:

		Second, w/r/t to this:

		       Furthermore, Oauth 1.0 defines three signature
methods used to
		protect requests, namely PLAINTEXT, HMAC-SHA1, and
RSA-SHA1. The group
		will work on new signature methods in case the existing
mechanisms do
		not fulfill the security requirements.

		Where are the "security requirements" coming from? Are
these defined
		separately? Whose are they?

		[hannes] I think a pragmatic approach is sensible here:
a document that
		describes a new mechanism might want to say what
requirements guided the
		solution and thereby provide some motivation.
		
		I was not thinking of an independent requirements
document. I don't
		think that it is well spent time.

	I agree.

	Maybe it was just the wording -- it sounded like there were some
definitive "security requirements" (or else you wouldn't be able to tell
if they were fulfilled!) but perhaps that's not what's intended there.

	I think I understand now: if you propose new security methods or
signing mechanisms, the document will describe why to use them in
situations with different security requirements. Ok.

	Thanks,

	Chris

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Feb 2009 10:44:05 -0800

On Mon, Feb 2, 2009 at 12:24 AM, Chris Messina <[email-masked]>wrote:

>
> ...
>  it sounded like there were some definitive "security requirements" (or
> else you wouldn't be able to tell if they were fulfilled!) but perhaps
> that's not what's intended there.
>

There are. The main ones are:
BCP 61, "*Strong Security Requirements for Internet Engineering Task Force
Standard Protocols* " <http://tools.ietf.org/html/rfc3365>
BCP 72, "*Guidelines for Writing RFC Text on Security Considerations* ", <
http://tools.ietf.org/html/rfc3552>

The IETF is not stellar at documenting everything that has come to be a
security requirement through popular demand, but we do have the above.

Lisa

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Feb 2009 11:49:45 -0700

Of course, even 'delegation' is a problematic term. HTTP Basic auth is not considered a delegation protocol but it really is. The End User gives the User Agent some credentials to access resources on its behalf on the Web Server. There is no restriction in Basic auth about the number of credentials used, so there could be a special one to give the browser.

Hmm. I guess that makes OAuth a 'goddamn goddamn protocol', if we replace all the problematic words... of course that does not help us at all.

I would not waste too much time trying to find a one liner to describe the protocol. And when in doubt, the Core 1.0 spec defines a framework for us to work with, and can always be used to draw the lines of what we are trying to solve.

EHL

---

From: Joseph A Holsten <[email-masked]>
Date: Mon, 2 Feb 2009 17:27:41 -0600

OAuth has two compontents. The authorization component is a very  
lightweight capabilities system which is mostly left up to the SP to  
define. It defines the requirements of the access token (capability)  
and how to access the resource. It does not currently provide the  
fine grained control that an authz protocol usually provides (see c- 
lists, acls). It doesn't need it, but is the right place for it if  
such control were necessary. The key is that this capability grants  
access to a resource, therefore it is authz.

The other part is very similar to Kerberos ticket granting, which you  
might call token negotiation, brokered authentication, or delegation.  
This is about requesting the access token. It is completely optional,  
and may be left out (see thmbnl implementation), or replaced (see  
hybrid protocol). While this used to be a service provided by  
authentication protocols, clearly OAuth proves that ticket granting  
and authentication may be separate protocols. OAuth could become  
authn by stating what credentials could be sent directly to the  
Authorization endpoint. If this was defined, then OAuth would be  
functionally equivalent to a Kerberos TGS or WS-Trust STS. Normally  
these protocols do not necessarily grant access to any resource,  
clearly putting them outside the realm of authz. Since OAuth does  
grant access, it is unique among protocols.

No I don't think they belong in separate specs, but it is useful to  
look at this in terms of traditional security protocols. But what  
matters is not so much the terms, as matters the formalization of the  
protocol. I suggest we create a mailing list oauth-authz-authn- 
flamewar to continue this discussion.

http://josephholsten.com

On Feb 2, 2009, at 12:49 PM, Eran Hammer-Lahav wrote:

> Of course, even ‘delegation’ is a problematic term. HTTP Basic auth  
> is not considered a delegation protocol but it really is. The End  
> User gives the User Agent some credentials to access resources on  
> its behalf on the Web Server. There is no restriction in Basic auth  
> about the number of credentials used, so there could be a special  
> one to give the browser.
>
>
>
> Hmm. I guess that makes OAuth a ‘goddamn goddamn protocol’, if we  
> replace all the problematic words… of course that does not help us  
> at all.
>
>
>
> I would not waste too much time trying to find a one liner to  
> describe the protocol. And when in doubt, the Core 1.0 spec defines  
> a framework for us to work with, and can always be used to draw the  
> lines of what we are trying to solve.
>
>
>
> EHL
>
>
>

http://josephholsten.com