+1 to Brian -1 to the proposed text from Denis
> On Dec 8, 2017, at 8:48 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > > The privacy matter is already mentioned. Despite your many messages to this > WG and others about the so called ABC attack, I do not believe it warrants > treatment in this document or others. And your continued proposals to have it > included in documents have not gotten support. > > On Fri, Dec 8, 2017 at 2:46 PM, Denis <denis.i...@free.fr > <mailto:denis.i...@free.fr>> wrote: > RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states: > > All RFCs are required by RFC 2223 to contain a Security > Considerations section. The purpose of this is both to encourage > document authors to consider security in their designs and to inform > the reader of relevant security issues. This memo is intended to > provide guidance to RFC authors in service of both ends. > > Section 5 (Writing Security Considerations Sections) of RFC 3552 states: > > While it is not a requirement that any given protocol or system be > immune to all forms of attack, it is still necessary for authors to > consider as many forms as possible. Part of the purpose of the > Security Considerations section is to explain what attacks are out of > scope and what countermeasures can be applied to defend against them > > There should be a clear description of the kinds of threats on the > described protocol or technology. > > It is important to mention the threat related to collusion attacks. A > different wording could be used, > but the threat should be mentioned one way or another. > > RFC 6973 (Privacy Considerations for Internet Protocols) intends to provide a > similar set of guidelines > for considering privacy in protocol design. > > It is important to mention a current threat related to privacy. A different > wording could be used, > e.g. using the word "surveillance" as mentioned in 5.1.1 : "Surveillance is > the observation or monitoring > of an individual’s communications or activities", but the threat should be > mentioned one way or another. > > Denis > >> I believe the text would detract from the document. >> From: OAuth <oauth-boun...@ietf.org> <mailto:oauth-boun...@ietf.org> on >> behalf of Brian Campbell <bcampb...@pingidentity.com> >> <mailto:bcampb...@pingidentity.com> >> Sent: Friday, December 8, 2017 3:47:32 PM >> To: Denis >> Cc: oauth >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-10.txt >> >> As an individual, I do not believe that the proposed text should be >> incorporated into the draft. >> >> As one of the document editors, my responsibility is for the document to be >> of reasonable quality and to reflect the rough consensus of this Working >> Group. So I should ask the list more explicitly - are there other WG >> remembers who are in favor of the proposed text here (the text would have to >> be fixed up some too)? >> >> On Fri, Dec 1, 2017 at 11:12 AM, Denis <denis.i...@free.fr >> <mailto:denis.i...@free.fr>> wrote: >> Comments on draft-ietf-oauth-token-exchange-10 >> >> I propose the following rephrasing for sections 6 and 7: >> >> 6 . Security Considerations >> >> All of the normal security issues that are discussed in [JWT],especially in >> relationship to comparing URIs >> and dealing with unrecognized values, also apply here. In addition, both >> delegation and impersonation introduce >> unique security issues. Any time one user receives a token, the potential >> for abuse is a concern, >> since that user might be willing to collude with another user so that other >> user could use the token. >> >> Techniques like the binding of an access token to a TLS channel described >> elsewhere are ineffective since >> the legitimate user would be able to perform all the cryptographic >> computations that the other user would need >> to demonstrate the ownership of the token. The use of the "scp" claim is >> suggested to mitigate potential for >> such abuse, as it restricts the contexts in which the token can be >> exercised. If the issued access token scope >> allows to unambiguously identify the user, then that user is likely to be >> reluctant to collude with another user. >> However, if the issued access token scope only indicates that the user is >> over 18, then there is no risk >> for the original user to be discovered and in such a context a collusion may >> easily take place. >> This document does not specify techniques to prevent such a collusion to be >> successful. >> >> 7 . Privacy Considerations >> >> Tokens typically carry personal information and their usage in Token >> Exchange may reveal details of the target services >> being accessed. The resource and the audience parameters allow authorization >> servers to know where the issued access token >> will be used. This may be a privacy concern for some users. This document >> does not specify techniques to prevent >> authorization servers to know where the access tokens they issue will be >> used. >> >> Denis >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>> >>> Title : OAuth 2.0 Token Exchange >>> Authors : Michael B. Jones >>> Anthony Nadalin >>> Brian Campbell >>> John Bradley >>> Chuck Mortimore >>> Filename : draft-ietf-oauth-token-exchange-10.txt >>> Pages : 32 >>> Date : 2017-11-30 >>> >>> Abstract: >>> This specification defines a protocol for an HTTP- and JSON- based >>> Security Token Service (STS) by defining how to request and obtain >>> security tokens from OAuth 2.0 authorization servers, including >>> security tokens employing impersonation and delegation. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ >>> <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/> >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 >>> <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10 >>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10> >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 >>> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org >>> <http://tools.ietf.org/>. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >> material for the sole use of the intended recipient(s). Any review, use, >> distribution or disclosure by others is strictly prohibited. If you have >> received this communication in error, please notify the sender immediately >> by e-mail and delete the message and any file attachments from your >> computer. Thank you. > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
