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> on behalf of Brian Campbell <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 attools.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./

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to