So my suggestions would be; 1. I think that section 3 is a good starting point and I would stop at section 3 for the base specification 2. This should be only about implementing the protocol, not about the services described 3. remove any talk of DoS (as this would be up to the implementer of the service) section 3.3 4. remove anything about access token "scope" (its opaque) 3.5.3 5. remove anything about tokens (specific format) and authentication 6. remove Phishing attacks 3.5.2 7. remove 3.7.1.1.Security of Bearer tokens 8. remove 3.8.7. Plaintext storage of credentials
-----Original Message----- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Tuesday, November 09, 2010 11:14 PM To: oauth@ietf.org Cc: Nicolas Williams; Anthony Nadalin; Tschofenig, Hannes Subject: Re: [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** Am 10.11.2010 08:00, schrieb Nicolas Williams: > [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 oauth@ietf.org (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, tors...@lodderstedt.net 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. We are open to proposals. Please take a look on our document and propose a way to shorten the threat model. regards, Torsten. >> 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. > Sure. Procedurally speaking, that works. > > Nico _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
