Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Nat Sakimura <sakimura@gmail.com> Mon, 27 March 2017 12:27 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA0127449 for <oauth@ietfa.amsl.com>; Mon, 27 Mar 2017 05:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level:
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O286Yx8_DRgv for <oauth@ietfa.amsl.com>; Mon, 27 Mar 2017 05:27:01 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA96612940D for <oauth@ietf.org>; Mon, 27 Mar 2017 05:27:00 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id r45so35346001qte.3 for <oauth@ietf.org>; Mon, 27 Mar 2017 05:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ST7TXJlhOMxkDEuT6gV2CcEoaYUWYwSfgA6d3FpffWI=; b=tcjU/ADAoUXrFz9fJEoHbXU5fIvf16jk1zjvd6/KG+oEEzvs9TFpjCs2Df3/r1ojRq XFpMyHXqYsQX19I01KzS+ay2Cxl96S8tApfVVlwUbeQ8nP1nA+XViTVJT5OBjb8o0Hi2 k7VLjNbL6LWIzFmse2p6qxt++VSSN9hc47qm+pRTrH9yopFJ4aE9QDqmt2lkEovY5O+p kCGn4r2qlpMgkp7WesRF4bsVHOA4G2HGL8/VNyMSOQTzhOk6/5e7JZT5Jc2FvufQzuBn CB0uaTUuCXCKbddJOlI2+HTD8hOIaCkcPtx7uRf8ft2Fk1T8fN0r9UiRwW8f5uKAu9Mm C8Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ST7TXJlhOMxkDEuT6gV2CcEoaYUWYwSfgA6d3FpffWI=; b=siIh+nCX2o05kLa7U6yNP4rI7xURqkNAcKhKR8uXTx0jN1PmaYEGVRA3gXSLK54XdU i+DaC5MP0G12QXiYKgPvz1aWZYkZPAJs58rlBHowxIoSZZ9nNfOXxbbK60d2LkmEjPKy TSB3N+WOz8xGgHH3DBLUYRevBkP0zvAg3qTsU8Vhl1nG1ZvS3xKZKTbm4ESvpgTG2a1P b3Fkz/oWT/eNwi7hrsJBwYxD1nrUFIhwen0q9km+QCBcfQZqynxhCnOmat7+tE/DedKC pkMI7Niuenj1cfHTG+G7a2LmAfA3iZ+X4gkZtzVicIUPrg4hcAN1832mrjaYqAB65NtD 7vjQ==
X-Gm-Message-State: AFeK/H2QfkcQODwgsOutSqdh0Z/rLgY1YoJCay2kATWAeWA6UutS1rUWtDv9rXweSnaiLq20vqKoMAytukfrbQ==
X-Received: by 10.200.52.135 with SMTP id w7mr20669125qtb.136.1490617619513; Mon, 27 Mar 2017 05:26:59 -0700 (PDT)
MIME-Version: 1.0
References: <148858532832.15846.17124635719619343122.idtracker@ietfa.amsl.com> <CY4PR21MB0504F842748771485358717AF5380@CY4PR21MB0504.namprd21.prod.outlook.com> <9905FF1B-0E4A-459B-8322-6AC143092D42@lodderstedt.net> <2452F93F-BC4D-4F42-AD4C-85A0672BFBE8@adobe.com> <CABzCy2D=0kTCOgV2VAmR+BLUzsp0x58yq8S8+mykRoqC2mtuQw@mail.gmail.com> <9c814ef0-4df3-35ed-5453-dd8cad91b910@free.fr> <CABzCy2AqK0rCRRZ1w_KXiKNbzjqwSx+OMS2nSXnfjLsuE-cgvg@mail.gmail.com> <45feb0e5-d1e3-ca5a-e8c1-f9b44768d09b@free.fr>
In-Reply-To: <45feb0e5-d1e3-ca5a-e8c1-f9b44768d09b@free.fr>
From: Nat Sakimura <sakimura@gmail.com>
Date: Mon, 27 Mar 2017 12:26:49 +0000
Message-ID: <CABzCy2BFC5KaFpoEfDfMaU2cr6CJT+53Gkghmzjk75qzW+KKyA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a1141a706b518bf054bb575b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FbF0r44x61Lip3pV0ss-FG4bH4w>
Subject: Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 12:27:05 -0000

HI.

As pointed out in saag, the OAuth WG is not dealing with ABC attack. It is
out of scope for now at least.
The certs used is the certs of the client and not the subject/user. It is
the client authentication, not the user authentication.
In addition, authorization server knowing where the user is going with this
token is not an issue here.
The protected resource and the authorization server belongs to the same
administrative domain.

Best,

Nat


On Mon, Mar 27, 2017 at 3:46 AM Denis <denis.ietf@free.fr> wrote:

> Hi Nat,
>
> At present, I do not support the adoption of this document as a WG
> document since the different techniques
> that are being proposed have severe problems:
>
>
>    - When the JWT contains a jwk , jwkt#s256 or jwe, the method is
>    ineffective in case of a collusion between two users (ABC attack).
>    - When the JWT contains a x5t#s256, the JWT is linked to a hash value
>    of a certificate included in the JWT.
>    The server then knows a unique identifier of the user. Such a method
>    allows an easy linkage between all the accounts
>    of a given user on different resource servers, even when the JWT only contains
>    non-directly identifiable attributes.
>    Hence, it does not respect 'privacy by design' principles.
>
> In addition, if a fixed value is being used for the audience restriction
> parameter, e.g. a URL of the server, then the authorization server
> can easily know where the access tokens will be used and thus it will be
> in a position to act as Big Brother.
>
> You may however continue to progress this document as an individual
> contribution.
>
>
> Denis
>
> PS. I will not subscribe to bitbucket.org because I don't agree with the
> conditions of this site.
>
>
> Hi Denis,
>
> Thanks.
>
> Is it possible to file these separately at
> https://bitbucket.org/Nat/oauth-rjwtprof/issues?status=new&status=open so
> that each issue can be closed separately? (You need to login to bitbucket
> to do so.) Pull request would be nice, too, but we are going to do a bit of
> surgery on the spec as of now, so it might be wise to wait till after that
> to avoid conflicts.
>
> Also, it is not yet a WG document so please support it become one.
>
> Best,
>
> Nat Sakimura
>
> On Wed, Mar 22, 2017 at 5:15 AM Denis <denis.ietf@free.fr> wrote:
>
> Hi Nat,
>
>
> I have several comments on draft-sakimura-oauth-jpop-01 related to
> security or privacy.
>
>
> 1. The abstract states:
>
> Only the party in possession of a corresponding cryptographic key with the
> Jpop token can use it to get access
> to the associated resources unlike in the case of the bearer token
> described in [RFC6750] where any party
> in possession of the access token can access the resource.
>
> This is incorrect.
>
> Replace with:
>
> Any party able to use a corresponding private cryptographic key with the
> Jpop token can use it to get access
> to the associated resources unlike in the case of the bearer token
> described in [RFC6750] where any party
> in possession of the access token can access the resource.
>
>
>
> 2. In section 3, the text states:
>
>   aud  The identifier of the resource server.
>
> According to the content of RFC 7800:
>
> The "aud" (audience) claim identifies the recipients that the JWT is
> intended for. The interpretation of audience values is application specific.
>
> Replace with:
>
>   aud  The recipients that the JWT is intended for (the interpretation of
> audience values is application specific).
>
>
>
> 3. In section 3, the text states:
>
> cnf  The confirmation method.
>
>    Their semantics are defined in [RFC7519] and [RFC7800]
>
>
> This is incorrect: cnf is neither defined in [RFC7519] nor in [RFC7800].
>
>
>
> 4. In section 6.2, the text states:
>
> For this, the following steps are taken:
>
>    1.  The client prepares a nonce.
>
>    2.  The client creates JWS compact serialization over the nonce
> JSON Web Token Claims are listed at:
> https://www.iana.org/assignments/jwt/jwt.xhtml
>
> "nonce" has not been defined by the IANA, but is mentioned in OpenID
> Connect Core 1.0 incorporating errata set 1. It is described as :
>
>
>
> nonce
>
> String value used to associate a Client session with an ID Token, and to
> mitigate replay attacks. The value is passed through
> unmodified from the Authentication Request to the ID Token. If present in
> the ID Token, Clients MUST verify that the nonce
> Claim Value is equal to the value of the nonce parameter sent in the
> Authentication Request. If present in the Authentication Request,
> Authorization Servers MUST include a nonce Claim in the ID Token with the
> Claim Value being the nonce value sent in the Authentication Request.
> Authorization Servers SHOULD perform no other processing on nonce values
> used. The nonce value is a case sensitive string.
>
>
>
> I have several observations:
>
> a)     there is some difficulty to mandate the use of a parameter that is
> not registered by IANA.
>
> b)     the further processing of the nonce is not indicated in the text
>
> c)  The last sentence from the above description states: "Authorization
> Servers SHOULD perform no other processing on nonce values used"
> There is a practical problem with such a sentence since Authorization
> Servers would need to remember nonces for ever.
> Either that sentence should be deleted or the nonce shall be only used
> with a UTC time parameter included in the Authentication Request.
>
> In any case, the definition of a nonce as specified in OpenID Connect
> Core 1.0 incorporating errata set 1 should not be used and another
> parameter
> (e.g. rdn for random) should be defined and registered by IANA and used in
> combination with a UTC time parameter included in the Authentication
> Request.
> In this way, only the rdn received during the last X minutes will need to
> be remembered by the Authorization Servers.
>
>
> 5. The title of section 9.1 is: "Certificate validation"
>
> Change the title of this section into :
>
> "9.1. Common Name Constrained Token"
>
>
>
> 6. In section 9.1, the text states:
>
> The "cn" JWT confirmation method relies its security property on the
>
>    X.509 client certificate authentication.
>
> Replace with:
>
> The "cn" JWT confirmation method relies its security property by the
> inclusion of the Common Name (CN)
> that is part of the Distinguished Name (DN) of an X.509 certificate. The
> JWT is linked to the common name
> included in the certificate. Such a method is not privacy friendly since
> it allows an easy linkage between
> all the accounts of a given user on different resource servers.
>
>
>
> 7. Add a new section 9.2 to deal with the case of the cid.
>
> Proposed text:
>
> 9.2. Client ID Constrained Token
>
> The "cid" JWT confirmation method relies its security property on the
> assumption that the cid legitimately
> used by one server cannot be used by another user. It also relies on the
> assumption that the authentication data
> associated with "cid" combined with the "iss" will only be used by the
> legitimate user. This method is ineffective
> in case of a collusion between two users, since one user can perform all
> the computations needed by the other user.
>
>
>
> 8. In section 9.2, the text states:
>
> The client’s secret key must be kept securely. Otherwise, the notion of
> PoP breaks down.
>
> The PKIX group from the IETF is using the vocabulary private key / public
> key when asymmetric cryptography is being used
> and secret key when symmetric algorithms are being used (let us call a
> spade a spade).
>
> However, keeping a client's private key securely is not the right wording
> either. If the key is kept securely in a secure element
> (e.g. smart card), this is not enough, since the holder of the secure
> element may use this key for himself ... or worse for the benefit of
> someone else.
>
> Proposed change :
>
> 9.3. Key Constrained Token
>
> This method has four variants.
>
> When the JWT contains a jwk, the JWT confirmation method relies its
> security property on the assumption that the private key
> associated with the public key contained in the access token will only be
> used by the legitimate user. In order to avoid an easy linkage
> between user's accounts, this method presents the advantage that the key
> pair can be changed for every JWT. However, this method
> is ineffective in case of a collusion between two users, since one user
> can perform all the computations needed by the other user.
>
> When the JWT contains a jwkt#s256, the server must have a prior knowledge
> of the public key and the method relies its security property
> on the assumption that the private key associated with the public key
> contained in the access token will only be used by the legitimate user.
> Hence, this method is ineffective in case of a collusion between two
> users, since one user can perform all the computations needed
> by the other user.
>
> When the JWT contains a x5t#s256, the server must have a prior knowledge
> of the public key certificate. The JWT is then linked to a hash value
> of a certificate included in the JWT. The server knows a unique identifier
> of the user. Such a method is not privacy friendly since it allows
> an easy linkage between all the accounts of a given user on different
> resource servers.
>
> When the JWT contains a jwe, the JWT confirmation method relies its
> security property on the assumption that the secret key included
> in the JWT will only be used by the legitimate user. In order to avoid an
> easy linkage between user's accounts, this method presents
> the advantage that the secret key can be changed for every JWT. However,
> this method is ineffective in case of a collusion between two users,
> since one user can perform all the computations needed by the other user.
>
>
>
> 9. The text states in section 9.3:
>
> 9.3.  Audi*a*nce Restriction
>
> When using the signature method the client must specify to the AS the aud
> it intends to send the token to, so that it can be included in the AT.
>
> A malicious RS could receive a AT with no aud or a logical audience and
> then replay the AT and jws-on-nonce to the actual server.
>
>
> Proposed change in order to address privacy concerns :
>
> 9.4.  Audi*e*nce Restriction
>
> When using the signature method, the client must specify to the AS the aud
> it intends to send the token to, so that it can be included in the AT.
>
> RFC 7800 states that the interpretation of audience values is application
> specific. If a fixed value is being used, e.g. a URL of the server,
> then the authorization server can easily know where the access tokens will
> be used and thus is in a position to act as Big Brother.
> It is thus recommended to use a different value in the aud claims for each
> access token that contains no semantics in it but that the resource server
> can easily recognize.
>
> If a malicious RS receives an AT with no aud or a logical audience in it
> then it can replay the AT and jws-on-nonce to another server.
>
>  Denis
>
>
> HI Chairs,
>
> I would also like to ask 5 min. on Monday (as I cannot be on Friday) for
> The OAuth 2.0 Authorization Framework: JWT Pop Token Usage [1].
>
> [1] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-01
>
> It is capturing strong and rather urgent demands from the financial sector
> and would be great if it can be considered in the WG.
>
> Best,
>
> Nat Sakimura
>
> On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso <asanso@adobe.com> wrote:
>
> hi Torsten,
>
> good one. I personally I am looking forward to see this particular
> document find its way.
>
> IMHO this is something much needed.
>
> regards
>
> antonio
>
> On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
>
> Hi Chairs,
>
> I would like to request 5 minutes on Monday to briefly present the status
> of the security document. This is mainly to raise awareness in the group
> since I didn’t get that much input on it since Seoul.
>
> kind regards,
> Torsten.
>
> Am 18.03.2017 um 01:52 schrieb Mike Jones <Michael.Jones@microsoft.com>:
>
> Hi Chairs,
>
> I'd like to request that the following presentations be added to the
> agenda:
>
> OAuth Token Exchange (draft-ietf-oauth-token-exchange) - Mike Jones - 15
> minutes
> OAuth Authorization Server Metadata (draft-ietf-oauth-discovery) - Mike
> Jones - 15 minutes
>
> I'd also talked with Brian Campbell and I think he wants to lead this
> discussion, in part based on his implementation experience:
>
> OAuth Token Binding (draft-ietf-oauth-token-binding) - Brian Campbell - 30
> minutes
>
> (Brian may suggest a different amount of time)
>
> I agree that William Dennis should present about the OAuth Device Flow
> (draft-ietf-oauth-device-flow).
>
> For completeness, I don't think a presentation is needed about OAuth AMR
> Values (draft-ietf-oauth-amr-values) because it's now completed its IESG
> review.
>
> I'll look forward to seeing many of you in just over a week!
>
> -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org <oauth-bounces@ietf.org>] On
> Behalf Of "IETF Secretariat"
> Sent: Friday, March 3, 2017 3:55 PM
> To: oauth-chairs@ietf.org; smccammon@amsl.com
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for
> IETF 98
>
> Dear Stephanie McCammon,
>
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by the original
> request.
>
> oauth Session 1 (2:30:00)
>   Friday, Morning Session I 0900-1130
>   Room Name: Zurich C size: 100
>   ---------------------------------------------
>   oauth Session 2 (1:00:00)
>   Monday, Afternoon Session III 1710-1810
>   Room Name: Zurich C size: 100
>   ---------------------------------------------
>
>
>
> Request Information:
>
>
> ---------------------------------------------------------
> Working Group Name: Web Authorization Protocol Area Name: Security Area
> Session Requester: Stephanie McCammon
>
> Number of Sessions: 2
> Length of Session(s):  2.5 Hours, 1 Hour Number of Attendees: 50 Conflicts
> to Avoid:
> First Priority: saag core tls tokbind
>
>
>
>
> People who must be present:
> Hannes Tschofenig
> Kathleen Moriarty
> Derek Atkins
>
> Resources Requested:
> Projector in room
>
> Special Requests:
> Please avoid conflict with sec area BoFs.
> ---------------------------------------------------------
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463068122&sdata=5CIJnWs2VdLM9FUWt%2FWlOxIilp5N2vfr7b9elwhL%2BA4%3D&reserved=0
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>
>
> --

Nat Sakimura

Chairman of the Board, OpenID Foundation