Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05

[Stephen Farrell <[e-mail]>]

Since I'm told this is now ready, I've put this on the August 30th
telechat. Note there is an RFC editor note [1] calling for making
the reference to oauth core normative.

S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/writeup/

On 06/28/2012 04:21 AM, Phil Hunt wrote:
> Stephen
> 
> One more threat has come up in the core spec that is being looked at. As Torsten is heading out on vacation I have agreed to augment if needed with any supplementary text to the threat model.
> 
> Will keep you informed. 
> 
> Phil
> 
> On 2012-06-27, at 17:17, Stephen Farrell <[e-mail]> wrote:
> 
>>
>> Hiya,
>>
>> Great. I've asked for IETF LC to start. I'll go through
>> the changes below during that in case there's some more
>> follow up.
>>
>> Thanks,
>> S.
>>
>> On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote:
>>> Hi Stephen,
>>>
>>> I just submitted a new revision of the security document incorporating
>>> your review comments.
>>>
>>> Please find answers to your comments below.
>>>
>>> Thank you again for your detailed review. You helped us to significantly
>>> improve the document's quality.
>>>
>>> best regards,
>>> Torsten.
>>>
>>> Am 28.05.2012 20:34, schrieb Stephen Farrell:
>>>> Hi all,
>>>>
>>>> I've gotten the publication request for oauth-threatmodel
>>>> so here's my AD review of -05.
>>>>
>>>> Its quite a read (and a good one) but I've a bunch of
>>>> questions. Some of these will need fixing I suspect
>>>> but a lot are ok to fix later after IETF LC, depending
>>>> on whether the authors want to re-spin it before then
>>>> or not. But I'd like to at least see reactions to the
>>>> questions before I start IETF LC.
>>>>
>>>> Although there are many many nits and typos, those
>>>> don't actually make the document unreadable so
>>>> though I'd prefer to see 'em fixed now, I'm ok with
>>>> that happening later if its a problem to get it
>>>> all done now.
>>>>
>>>> If you want to argue for going ahead with IETF LC
>>>> now please do so, but I suspect that this might need
>>>> a revised ID to fix at least a couple of the points
>>>> raised below. If nobody does argue to go ahead now,
>>>> I'll mark it as revised ID needed, but first let's
>>>> see what the answers are to the questions.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>
>>>> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up.
>>> done
>>>> (2) You don't say anything about the probability of
>>>> occurrence of the various threats. I realise that you
>>>> can't be precise but it seems wrong to say nothing.  Would
>>>> it be worth at least saying that that's not done here and
>>>> that readers of this document need to do their own risk
>>>> analysis including that aspect?
>>>
>>> That's correct - I added the following paragraph to the introduction:
>>>
>>> "Note: This document cannot assess the probability nor the risk
>>> associated with a particular threat because those aspects strongly
>>> depend on the particular application and deployment OAuth is used to
>>> protect. Similar, impacts are given on a rather abstract level. But the
>>> information given here may serve as a foundation for deployment-specific
>>> threat models. Implementors may refine and detail the abstract threat
>>> model in order to account for the specific properties of their
>>> deployment and to come up with a risk analysis."
>>>
>>>> (3) Many deployments will use TLS accelerators.  That
>>>> means that TLS isn't fully e2e, and that opens up some
>>>> (mainly) insider attacks or attacks that can be launched
>>>> from within a compromised DMZ, but from outside the server
>>>> applications. Does that need a mention somewhere? (I've
>>>> seen systems like that deployed and a lot could go wrong
>>>> from the inside, so I think this is a real threat.)
>>>
>>> I added another paragraph to section 5.1.1:
>>>
>>> "Note: this document assumes end-to-end TLS protected connections
>>> between the respective protocol entities. Deployments deviating from
>>> this assumption by offloading TLS in between (e.g. on the data center
>>> edge) must refine this threat model in order to account for the
>>> additional (mainly insider) threat this may cause."
>>>
>>>> (4) Could you use just one of "client identity" or "client
>>>> identifier" consistently? I'd much prefer the latter,
>>>> which has also been the outcome of various discussions on
>>>> this topic elsewhere. For example you say "revocation of
>>>> such an identity" at the end of p13, and that's a
>>>> potential rathole, better to say "revocation of the rights
>>>> associated with a client identifier" or similar I think.
>>>> And similar changes throughout.
>>>
>>> Replaced client identity by client identifier in most places and
>>> incorporated your proposed text
>>>
>>>> (5) 4.4.2.2: Here you recommend native applications should
>>>> use an embedded browser, but earlier you said that was a
>>>> bad idea. I think you need to be consistent or else
>>>> provide more about when its ok to embed and when its not.
>>>> Did I misread it or does that need a change?
>>>
>>> removed 3rd bullet as native apps should use code flow
>>>
>>> We also removed the 1st bullet in 4.4.1.9
>>>
>>>> (6) 4.4.3.1: This calls for "obfuscation" of passwords in
>>>> logs. I think you ought be stronger there and call for
>>>> strong encryption of passwords wherever they are stored,
>>>> be that logs or DBs or whatever. Would'nt that be reasonable?
>>>
>>> This section is about preventing accidential exposure by the client. I
>>> think encryption is not appropriate here since the password is entered
>>> in the clear by the user. I added the advice to encrypt credentials as
>>> alternative means to salted hashes to 5.1.4.1.3.
>>>
>>>> (7) 4.6.4: 1st countermeasure: I don't think you mean
>>>> address here (in the sense of an IP address, which is what
>>>> that means) but rather the domain name or FQDN or URL.  In
>>>> any case, you need to say what is meant clearly.  (Also in
>>>> 5.1.5.6 and elsewhere when you use the term "address".)
>>>
>>> replaced address in most cases by URL and in some place by FDQN
>>>
>>>> (8) 4.6.6: You say to use Cache-Control, but don't say
>>>> how.  Is more needed really? Maybe there's a good document
>>>> you could reference for that? (I'm not suggesting you add
>>>> a lecture on caching btw:-)
>>>
>>> Added text from core spec describing usage of Cache-Control and Pragma
>>> response header fields
>>>
>>>> (9) 5.1.1: needs a reference to RFC 5246 (and better to
>>>> just say TLS and not say SSL, at least for me :-)
>>>
>>> done
>>>> (10) 5.1.1: needs a reference to whatever you mean by
>>>> "VPN" since there are many types of VPN. I assume you mean
>>>> an IPsec VPN? But even if not, saying more would be good.
>>>
>>> Extended description and added reference to RFC 4301.
>>>> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125
>>>> and/or RFC 2818. Bascially, you need to say how this is
>>>> done (by reference).
>>>
>>> Added reference to RFC 2818 since it seems to be closest to the problem
>>>
>>>> (12) 5.1.4.1: Isn't there some good reference you can give
>>>> here? (Having said that, I'd have to go look myself, but
>>>> I'd maybe start with owasp or sans.)
>>>
>>> added reference to OWASP
>>>
>>>> (13) 5.1.4.2.2: if p(collision) should be <=2^(-160) then
>>>> what's the point of saying it ought be <= 2^(-128)? Also
>>>> if sha-1 were perfect, then the 160 bits output would
>>>> really have a collision probability of about 2^(-80) with
>>>> many many tokens, but not 2^(-160). I think you need
>>>> to fix something there.  Perhaps you're really saying that
>>>> all high-entropy secrets should be >=128 bits long and
>>>> constructed with a good (P)RNG? If so, saying so more
>>>> clearly would be better. Not everyone will get the
>>>> collision probability way of saying that even when its
>>>> properly stated. (This text is also repeated, be better if
>>>> you just said this once I think.)
>>>
>>> modified text as follows
>>>
>>> "When creating secrets not intended for usage by human users (e.g.
>>> client secrets or token handles), the authorization server should
>>> include a reasonable level of entropy in order to mitigate the risk of
>>> guessing attacks. The token value should be >=128 bits long and
>>> constructed from a cryptographically strong random or pseudo-random
>>> number sequence (see [RFC4086] for best current practice) generated by
>>> the Authorization Server."
>>>
>>> removed 5.1.5.11. (redundant text) and updated references accordingly
>>>
>>>> (14) 5.1.5.2: what is a "reasonable duration" - I don't
>>>> think its ok to say that but nothing else. Can't you give
>>>> some "reasonable" examples based on current usage?
>>>
>>> added examples and explanation of factors determining reasonable
>>> expiration time
>>>
>>> "Tokens should generally expire after a reasonable duration. This
>>> complements and strengthens other security measures (such as signatures)
>>> and reduces the impact of all kinds of token leaks. Depending on the
>>> risk associated with a token leakage, tokens may expire after a few
>>> minutes (e.g. for payment transactions) or stay valid for hours (e.g.
>>> read access to contacts).
>>>
>>> The expiration time is determined by a couple of factors, including:
>>>
>>> - risk associated to a token leakage
>>> - duration of the underlying access grant,
>>> - duration until the modification of an access grant should take effect,
>>> and
>>> - time required for an attacker to guess or produce valid token."
>>>
>>>> (15) 5.1.5.5: needs a reference to SAML assertions with
>>>> the current text.
>>>
>>> done - also added reference to RFC4120 in section 3.1
>>>> (16) 5.2.2.3: this describes a refresh token rotation
>>>> scheme that I don't recall being discussed on the list, so
>>>> this is just to check that that rotation scheme, as
>>>> described, doesn't ring any alarms bells for the WG. If
>>>> not, that's fine. And if it was discussed on the list and
>>>> I've forgotten, then sorry about that:-)
>>>
>>> It has been discussed, the first time with the introduction of the
>>> option to return a new referesh token value in response to a refresh
>>> token grant request. A more recent discussion can be found here:
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html
>>>
>>>> (17) 5.2.2.5: Using IMEI's like this has privacy
>>>> implications that I think you ought call out. A single
>>>> sentence and a reference to something that says "be
>>>> careful about privacy here" would be fine I'd say. (And
>>>> you need a reference for "IMEI" and to expand the term.)
>>>
>>> added note and reference to respective 3gpp spec
>>>
>>>> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION.
>>>> There's a websec draft about that I think.
>>>
>>> added reference to
>>> http://tools.ietf.org/html/draft-gondrom-x-frame-options/
>>>> (19) 5.2.3.4: what do you mean when you say "for different
>>>> deployments of a client"? That could be one secret per
>>>> install or one secret for all customers of a mobile
>>>> operator and those are radically different. I think you
>>>> need to be clear and hope you mean the former. That's
>>>> almost cleared up in the 3rd paragraph of the section but
>>>> I wanted to just check. Not sure "deployment" is the best
>>>> term there really - what's wrong with "installation"?
>>>
>>> nothing is wrong with "installation" :-)
>>>
>>> replaced deployment by installation and partially re-phrased section
>>>
>>>> (many:-) nits and typos:
>>>>
>>>> 2.3.1: maybe explain "handle-based design" or give a
>>>> reference? (Or maybe just a forward ref to 3.1?)
>>>
>>> added ref to 3.1
>>>> 2.3.3: It might be worth re-iterating that the term
>>>> "client" in oauth is used differently, e.g.  by copying a
>>>> bit of text from the base spec. I can see folks being
>>>> confused by this otherwise.
>>>
>>> copied a sentence from base spec and extended description
>>>
>>>> 3.1: "is digitally signed" - do you mean it has data
>>>> integrity and origin authentication?  If MACs are commonly
>>>> used (or maybe authenticated encryption), and not
>>>> necessarily signatures, then saying that would be better.
>>>
>>> we mean data integrity and origin authentication - added some text to
>>> explain this
>>>
>>>> 3.1.2: typo: s/this mechanisms/this mechanism/
>>>>
>>>> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in
>>>> the base spec? I think it'd be better not to capitalise
>>>> this in case it finds its way into someone's code. You
>>>> could also use "Expires In" in the title and then say that
>>>> its "expires_in" in the protocol. Might be worth doing
>>>> something generic to call out when you're talking about
>>>> specific things from the protocol, e.g. use a convention
>>>> like ``expires_in'' or "expires_in" consistently and say
>>>> that in the intro.
>>>
>>> Renamed section to "Limited access token limetime" and changed wording
>>> to explicitely distinct between concept and protocol parameter.
>>>
>>>> 3.4: typo: s/the later/the latter/
>>>>
>>>> 3.4: bullet item 1 isn't really a reason for anything but
>>>> a downside of doing this, at least as written. Maybe this
>>>> needs to be tweaked?
>>>
>>> tweaked it
>>>> 3.6: expand CSRF on 1st use and maybe give a reference
>>>> CSRF is expanded in 4.4.1.8 which is a good bit later,
>>>> and also in 4.4.2.5 which could presumably be
>>>> shortened a bit by removing the repetition.
>>>
>>> expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened
>>> 4.4.2.5
>>>
>>>> 3.7: typo: s/collage associated request/collate associated
>>>> requests/
>>>>
>>>> 3.7: Maybe give a pointer to the definition of "native
>>>> application" in the base spec (Its section 9 of that.)
>>>> 2nd last para of p13 would be a good place for that.
>>>
>>> added pointer
>>>
>>>> section 4: maybe s/Security Threat Model/Threat Model/
>>>> in the section title - what other kind of threat
>>>> model is there?
>>>
>>> changed to Threat Model
>>>
>>>> section 4: I wondered how we know the threat model
>>>> is "comprehensive"? Perhaps "detailed" is better?
>>>
>>> We are rather confident because we created the threat model a systematic
>>> way and had it reviewed by a lot of security folks
>>>
>>>> 4.2.1: typo: s/Users/users/g unless you mean something
>>>> special?
>>>>
>>>> 4.2.2: typo: s/a understandable/an understandable/
>>>>
>>>> 4.2.2: "...based on who the client is." is unclear
>>>> and not gramatically nice:-) "...based on the client
>>>> identifier." would seem better.
>>>>
>>>> 4.3.1: typo? s/on transit/in transit/ Or did you
>>>> mean something else? and s/may attempts/may attempt/
>>>>
>>>> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad
>>>> less biblical:-)
>>>
>>> changed to "Revelation of client credentials during transmission"
>>>
>>>> 4.3.3: typo? 1st countermeasure reads oddly and
>>>> refers to a different place than other references
>>>> to TLS - is that correct?
>>>
>>> changed to standard wording
>>>
>>>> 4.3.3: digest auth is nearly the same as sending
>>>> credentials over the wire, TLS client auth based
>>>> on certificates would be a better example, even
>>>> if its not often done.
>>>
>>> Isn't TLS client authentication always combined with TLS protected
>>> communication? So this would merly be an additional and not alternative
>>> mechanism.
>>>
>>>> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't.
>>>> Maybe it ought to?
>>>
>>> Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should
>>> point back to 4.3.2?
>>>
>>>> 4.3.6: typo s/an authorization servers/an authorization
>>>> server/
>>>>
>>>> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there
>>>> a reason to not do that here too?
>>>
>>> this section discussed a potential threat on dynamic client
>>> registration. Wen decided to remove the whole section as dynamic client
>>> registration is subject of current charter and respective security
>>> considerations should delt with in this context.
>>>
>>>> 4.4: typo? s/tokens endpoint/token endpoint/ ?
>>>>
>>>> 4.4.1.1: typo: s/by different ways/in different ways/
>>>>
>>>> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field,
>>>> but you fixed their typo here - might be better to live
>>>> with the bad spelling, in which case
>>>> s/referrer/referer/g;-)
>>>
>>> ok :-)
>>>
>>>> 4.4.1.1: Is there no better way to reference these
>>>> OASIS docs? More importantly, is there no better (more
>>>> stable) reference than thomasgross.net for the
>>>> PDF you reference? Tidying this up would be good.
>>>
>>> added references to OASIS documents and stable reference to 3rd document
>>> in proceedings of Computer Security Applications Conference
>>>
>>>> 4.4.1.1 and elsewhere: a few times you say "such as
>>>> TLS or SSL," I think it'd be better to just say TLS
>>>> there and do it consistently everwhere. In other
>>>> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd
>>>> be better done consistently.
>>>
>>> removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS
>>> for the more specific case of HTTP+TLS
>>>
>>>> 4.4.1.1: typo: s/redeem a authorization code/redeem
>>>> an authorizatio code/
>>>>
>>>> 4.4.1.4: "counterfeit a valid client" reads oddly,
>>>> do you mean "pretend to be a valid client"? If so,
>>>> I think that'd be clearer.
>>>>
>>>> 4.4.1.4: "and to prevent unauthorized access to
>>>> them" - I think you might add "via the oauth
>>>> protocol" there since the AS isn't responsible for
>>>> all possible ways of preventing unauthorized access.
>>>>
>>>> 4.4.1.4: typo: s/not neccesserily indicates/doesn't
>>>> necessarily indicate/
>>>>
>>>> 4.4.1.4: typo: s/user should be explained the purpose/
>>>> something better/ :-)
>>>
>>> tried my best:
>>>
>>> "In this context, the authorization server should explain to the
>>> end-user the purpose, scope, and duration of the authorization the
>>> client asked for. "
>>>
>>>
>>>> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a
>>>> reference for this too. Especially since you also
>>>> have 5.1.4.2.5, which is maybe the best place for
>>>> the reference.
>>>
>>> Changed counter measure paragraph from:
>>> "If the authorization server automatically authenticates the end-
>>>      user, it may nevertheless require some user input in order to
>>>      prevent screen scraping.  Examples are CAPTCHAs or user-specific
>>>      secrets like PIN codes."
>>> to:
>>> "If the authorization server automatically authenticates the end-user,
>>> it may nevertheless require some user input in order to prevent screen
>>> scraping. Examples are CAPTCHAs (Completely Automated Public Turing test
>>> to tell Computers and Humans Apart) or other multi-factor authentication
>>> techniques such as random questions, token code generators, etc."
>>>
>>>
>>>> 4.4.1.4: isn't a PIN code another user authentiation?
>>>> Seems like a bad example of automatic authentication,
>>>> since it isn't automatic if the user has to enter a
>>>> PIN.
>>>
>>> see above
>>>> 4.4.1.6: Is Facebook a trademark? Maybe better to not
>>>> use that if so?
>>>
>>> Changed Facebook reference section to:
>>> (e.g. as in the implementation of "Login" button to a third-party social
>>> network site)
>>>
>>>
>>>> 4.4.1.7: typo: s/achieve that goal/achieves that goal/
>>>>
>>>> 4.4.1.7: typo: s/victims resources/victim's resources/
>>>>
>>>> 4.4.1.7: typo: s/The attackers gains/The attacker gains/
>>>>
>>>> 4.4.1.7: typo: s/then the target web site/rather than
>>>> the target web site/
>>>>
>>>> 4.4.1.7: "session fixation" could do with a reference
>>>> or definition, and that might be better earlier in
>>>> this section and not just in the countermeasures
>>>> part.
>>>
>>> changed
>>>
>>> "The authorization server may also enforce the usage and validation of
>>> pre-registered redirect URIs (see Section 5.2.3.5).  This will allow for
>>> an early recognition of session fixation attempts."
>>> to:
>>> "The authorization server may also enforce the usage and validation of
>>> pre-registered redirect URIs (see Section 5.2.3.5).  This will allow for
>>> an early recognition of authorization code disclosure to counterfeit
>>> clients."
>>>
>>>
>>>> 4.4.1.7: typo: s/kind of attacks/kind of attack/
>>>>
>>>> 4.4.1.8: typo: s/not follow untrusted/to not follow
>>>> untrusted/
>>>>
>>>> 4.4.1.9: maybe add a reference for "iframe"? And
>>>> you say "iFrames" later, better to be consistent.
>>>>
>>>> 4.4.1.9: 1st countermeasure - do you mean end-user
>>>> authorization here or end-user authentication? And
>>>> would it be better to say "system browser" or
>>>> something rather than "external browser"? (I forget
>>>> what phrase you used for that earlier but there
>>>> was something bettter:-)
>>>
>>> We mean "authorization"
>>>
>>> We came to the conclusion that it does not matter in which browser the
>>> page is loaded - removed 1st bullet
>>>
>>>> 4.4.1.9: "javascript framebusting" really needs
>>>> a reference
>>> added
>>>> 4.4.1.10: typo: s/the victims resources/the victim's
>>>> resources/
>>>>
>>>> 4.4.1.10: typo: s/or split the/or splits the/
>>>>
>>>> 4.4.1.10: "corresponding form post requests" isn't
>>>> clear to me - does that need rephrasing or is it
>>>> just me?
>>>>
>>>> 4.4.1.10: this is the first mention of cookies, which
>>>> I found surprising, but that's all;-)
>>>>
>>>> 4.4.1.10: the 2nd "ways to achieve this" bullet is
>>>> a bit unclear - which "It" and whose browser? I
>>>> think this could be clearer.
>>>>
>>>> 4.4.1.10: typo: s/as native app/as a native application/
>>>>
>>>> 4.4.1.10: what does "assume" the threat mean?
>>>>
>>>> 4.4.1.10: typo: s/an user interaction/a user interaction/
>>>>
>>>> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get
>>>> rid of the "or" from the last bullet
>>>>
>>>> 4.4.1.10: typo: s/send out of bound/sent out of band/
>>>>
>>>> 4.4.1.10: typo: s/instance message/instant message/
>>>
>>> considerably re-worded this section
>>>
>>>> 4.4.1.11: typo? s/directing user(s) browser/directing
>>>> the user's browser/ ?
>>>>
>>>> 4.4.1.11: I don't get the explanation here. Are you
>>>> assuming (but not saying) that generating non-trivial
>>>> entropy is a slow process? (e.g. /dev/random blocking?)
>>>> Its also not clear what "pool" you mean? This probably
>>>> needs a bit of tweaking.
>>>>
>>>> 4.4.1.12: semicomplete.com may not be a sufficiently
>>>> stable reference - can't you find a better one?
>>>
>>> unfortunately not
>>>> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses
>>>> such as rate limiting/
>>>>
>>>> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing
>>>> system/
>>>>
>>>> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing
>>>> system/ :-)
>>>>
>>>> 4.4.1.12: typo? maybe s/iframe/iFrame/ again?
>>>>
>>>> 4.4.1.12: 1st reference to "the CSRF token" here? That
>>>> might warrant a reference of some sort? (Maybe to
>>>> a later section?)
>>>>
>>>> 4.4.1.12: Facebook again.
>>>>
>>>> 4.4.1.12: Signing the code seems like a bit of a hack.  Do
>>>> you really want to recommend this here? I suspect it'd end
>>>> up different if you actually tried it out aiming for an
>>>> interoperable solution. I'd suggest deleting this, or
>>>> maybe make it less specific, e.g. saying if origin
>>>> authentication for authorization codes could be validated
>>>> by clients, then that'd be a countermeasure, but that
>>>> there's no current spec for that. (And doing that might
>>>> just move the DoS to somewhere else depending how you
>>>> did it.)
>>>>
>>>> 4.4.2: typo: s/and It cannot/and it cannot/
>>>>
>>>> 4.4.2.1: Is the countermeasure here TLS? If so, better to
>>>> say so.
>>>>
>>>> 4.4.2.2: requests aren't cached are they but rather
>>>> responses?
>>>>
>>>> 4.4.2.3: typo: s/An malicious/A malicious/
>>>>
>>>> 4.4.2.3: The reference back to 4.4.1.4 isn't very
>>>> clear since a lot of the countermeasures there
>>>> mention authentication. It'd be better to explicitly
>>>> list things here or else if you stick with the
>>>> backwards reference to be more explicit about whic
>>>> exactly apply.
>>>>
>>>> 4.4.2.5: Is this entirely identical to 4.4.1.8? That
>>>> doesn't seem right. If it is, then say so explicitly.
>>>> If not, then say what's different.
>>>>
>>>> 4.4.3: 1st mention of username/password anti-pattern,
>>>> so you could add a reference
>>>>
>>>> 4.4.3: Be good to metion here that passwords are often
>>>> used for >1 service, so this anti-pattern risks whatever
>>>> else is accessible with that credential or an
>>>> algorithmically derivable equivalent (e.g.
>>>> [e-mail]/pwd  might easily allow someone to guess
>>>> that the same pwd is used [e-mail]) and
>>>> then another countermeasure is to educate users to
>>>> not use the same pwd for multiple services (hard as
>>>> that is to really do;-)
>>>>
>>>> 4.4.3.4: again digest auth isn't a good example
>>>> here, but client certs are.
>>>>
>>>> 4.4.3.6: What does "Abandon on grant type..." mean?
>>>> If you mean "don't do this" then say that more
>>>> clearly.
>>>
>>> Changed to "Consider not to use grant type "password""
>>>
>>>> 4.6.2: typo: s/transport security measure/transport
>>>> security measures/ or maybe just say TLS
>>>>
>>>> 4.6.2: typo: s/nounces/nonces/
>>>>
>>>> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/
>>>> I don't see why "difficult" guessing is hard enough?
>>>>
>>>> 4.6.4: typo: s/a valid access tokens/a valid access token/
>>>>
>>>> 4.6.4: Do you mean the IP address in the 2nd
>>>> countermeasure?  I'm not sure, esp. given the above.
>>>>
>>>> 4.6.4: typo: s/miss the capabilities/lack the capability/
>>>>
>>>> 4.6.6: reference to 2616 is broken
>>>>
>>>> 4.6.6: Should you reference httpbis drafts? Just asking, I
>>>> can see arguments for referencing just 2616 or just
>>>> httpbis or both, given that this'll be read for hopefully
>>>> a while after httpbis is done.
>>>>
>>>> 4.6.7: referrer vs. referer again
>>>>
>>>> 4.6.7: What is an appropriat logging configuration? Can
>>>> you give a reference maybe or is it really that well
>>>> known?
>>>>
>>>> 4.6.7: Reloading the target page again? Are you really
>>>> recommending that?
>>>>
>>>> 5.1: typo: s/consideratios/considerations/
>>>>
>>>> 5.1.3: I think you should note the email notifications
>>>> can be a phishing vector so don't make your emails
>>>> such that lookalike phish messages can easily be
>>>> derived from them.
>>>>
>>>> 5.1.3: Don't you need to say something about getting
>>>> email notifications delivered and not treated as spam?
>>>> Maybe you could recommend dkim here or other ways to
>>>> get better delivery. (Not sure myself, probably best
>>>> to ask someone who operates like this so see if there's
>>>> stuff to be said.)
>>>>
>>>> 5.1.4.1.3: typo: s/not store credential/not store
>>>> credentials/
>>>>
>>>> 5.1.4.1.4: salted hashes don't prevent offline
>>>> dictionary attacks, they just increase the workload
>>>>
>>>> 5.1.5.1.4: would it be worthwhile recommending that
>>>> different client credentials be used in development
>>>> or integration mode vs. when operational? I've seen
>>>> a bunch of times when programmers were given "live"
>>>> API keys when that could've been avoided.
>>>>
>>>> 5.1.4.1.5: I don't get this. If it was only that
>>>> easy:-) I think you need to say which private keys
>>>> are used here and for what for this section to be
>>>> useful.
>>>>
>>>> 5.1.4.2.1: I think you could note that complex password
>>>> policies can also increase the liklihood that users
>>>> re-use passwords or write them down or store them
>>>> somewhere not so good, if e.g. the entropy required
>>>> over all the user's passwords (dozens usually) is
>>>> too great for long-term memory.
>>>>
>>>> 5.1.5.1: typo: s/Basis of/The basis of/
>>>>
>>>> 5.1.5.1: typo: s/sensible service/sensitive service/
>>>> (2nd best typo:-)
>>>>
>>>> 5.1.5.3: typo: s/preciser/more precise/
>>>>
>>>> 5.1.5.3: typo: s/refreshments/refreshes/
>>>>
>>>> 5.1.5.4: 2nd bullet is not a threat but a goal
>>>>
>>>> 5.1.5.4: typo: s/redeem a/redeem an/
>>>>
>>>> 5.1.5.5: what is a "rough" server? Do you mean rogue?
>>>>
>>>> 5.5.5.6: I think you need to clarify what "address"
>>>> means here too.
>>>>
>>>> 5.1.5.9: please clarify if you mean digitally signed
>>>> (asymmetric) or also include MACing here
>>>>
>>>> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/
>>>>
>>>> 5.1.5.10: s/privacy/confidentiality/ ?
>>>>
>>>> 5.1.5.10: this (typically, I'd guess) requires sharing
>>>> symmetric keys between server nodes, so you should
>>>> say that as its a bunch of work.
>>>>
>>>> 5.1.5.11: I don't get why you want to repeat this
>>>> text (and its error:-) better to refer back to
>>>> the earlier section I think.
>>>>
>>>> 5.1.5.12: Another place where a SAML reference would
>>>> be needed.
>>>>
>>>> 5.1.6: 2nd bullet is not a "measure" but a goal. If
>>>> you had something in mind, it doesn't come out from
>>>> that text.
>>>>
>>>> 5.2.2.2: You say the binding should be protected, but
>>>> don't say how. I think you ought.
>>>>
>>>> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe
>>>> better to delete the word
>>>>
>>>> 5.2.3: 2nd bullet - "trustworthiness" has gotta
>>>> be the wrong word there, what did you mean?
>>>>
>>>> 5.2.3: typo: s/statics/statistics/
>>>>
>>>> 5.2.3: typo: s/support achieve objectives/achieve these
>>>> objectives/ ?
>>>>
>>>> 5.2.3: typo: s/by hand of an administrator/something
>>>> better/
>>>>
>>>> 5.2.3.1: "prevents...overestimating" seems wrong, I think
>>>> you mean it reduces the probability of mistakenly treating
>>>> a useless authentication as a good one. (The point is
>>>> that servers don't "overestimate," only people do that.)
>>>>
>>>> 5.2.3.1: "cannot be entirely protected" seems like
>>>> understatement - the reality is any such secret will
>>>> leak out from anything that's any way successful. It
>>>> only protects stuff that *nobody* cares about.
>>>>
>>>> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it
>>>> to not use the terms "trust" nor "identity" and then
>>>> it'd be better I think.
>>>>
>>>> 5.2.3.2: typo? s/The authorization may/The authrozation
>>>> server may/ ? Not sure what "issue a cliend id" means
>>>> either. (Same in 5.2.3.3)
>>>>
>>>> 5.2.3.4: typo: s/A authorization server/An authorization
>>>> server/
>>>>
>>>> 5.2.3.5: what are "validated properties"?
>>>>
>>>> 5.2.3.5: what is the 1st bullet list on p57? there's
>>>> no introductory text?
>>>>
>>>> 5.2.3.5: the "it" in "it only works" in the last
>>>> paragraph isn't clear - which "it" do you mean?
>>>>
>>>> 5.2.3.5: saying discovery "gets involved" seems
>>>> wrong - do you mean "is used"? And what is the
>>>> "that" in "that's no longer feasible"?
>>>>
>>>> 5.2.3.6: typo: s/be unintentionally for/unintentionally
>>>> affect/?
>>>>
>>>> 5.2.3.7: typo: s/to distribute client_secret/to
>>>> distribute a client_secret/
>>>>
>>>> 5.2.4.1: Is a "security certificate" a public key
>>>> certificate? If so, saying that is better.
>>>>
>>>> 5.2.4.1: the references to 5.7.2.x are wrong and
>>>> look like you're missing some xref's in the xml
>>>> maybe
>>>>
>>>> 5.2.4.2: you said "address" again, so the usual
>>>> question arises :-)
>>>>
>>>> 5.2.4.3: typo: s/in all situation/in situations/
>>>> (not sure "all" is right so suggest deleting it)
>>>>
>>>> 5.2.4.4: again, be good to say how to protect
>>>> the binding
>>>>
>>>> 5.2.4.5: as for 5.2.4.4 say how binding is done
>>>>
>>>> 5.3.1: typo: s/a associated/an associated/
>>>>
>>>> 5.3.1: "entirely protected" is (again:-) understatement
>>>> see above for a suggestion
>>>>
>>>> 5.3.1: what does "trust on the client's identity" mean?
>>>> Its not clear anyway
>>>>
>>>> 5.3.3: typo: s/operation systems/operating systems/
>>>> (enrire 2nd & 3rd paras could do with re-phrasing)
>>>>
>>>> 5.3.4: typo: s/their level/the level/
>>>>
>>>> 5.3.5: this is too terse - is it really finished? I'd
>>>> say there's a sentence or two missing.
>>>>
>>>> 5.4.2: what does it mean to "encourage resource
>>>> servers" to do something? I guess you mean to encourage
>>>> the people deploying those to pick resource servers
>>>> with that capability and to turn that on.
>>>>
>>>> 5.4.2: not sure if everyone will know what a
>>>> "distinguished name" is, maybe add a reference to
>>>> rfc 5280?
>>>>
>>>> 5.4.2: token-bound secrets would be used to MAC
>>>> the request and not to sign, be better to make that
>>>> clear even if you still call that "signing" here
>>>> (its not really, if we're being pedantic)
>>>>
>>>> 5.4.2: typo: s/This mechanisms/This mechanism/
>>>>
>>>> 5.4.2 and 5.4.3: I forget - where are the protocol
>>>> mechanisms for this defined? Can you give a reference
>>>> or say that its future stuff if there aren't any
>>>> good ones?
>>>>
>>>> 5.5: typo: s/capable to validate/capable of validating/
>>>>
>>>> 8.1: Is the base spec really normative? I'd say you're
>>>> fine with that as informative too.
>>>>
>>>> 8.2: there are a bunch of references missing as per
>>>> the questions above
>>>>
>>>> 8.2: is there no better (more stable) reference than
>>>> portablecontacts.net?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>