Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98
Nat Sakimura <sakimura@gmail.com> Sun, 26 March 2017 16:37 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 7FCC312964B for <oauth@ietfa.amsl.com>; Sun, 26 Mar 2017 09:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ELsN5RTewvtK for <oauth@ietfa.amsl.com>; Sun, 26 Mar 2017 09:37:30 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 0E4DD1295B3 for <oauth@ietf.org>; Sun, 26 Mar 2017 09:37:30 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id i34so21913500qtc.0 for <oauth@ietf.org>; Sun, 26 Mar 2017 09:37:30 -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=CmqzKP0T4T+l6RBtxGDaT8Y3wCnO7gw35hGfRraqPwk=; b=qF7ShQGWeXIVb0A1XFP4AtCN910Uu4aCxemAc/YotijZeKFK157ZZZOg7RypDcFUqM SDUI8KtAxeCvxy2XVBNMzJRxuFNAskdhq3loqDd7BQOSe2Ei/MP4fG9fAnqQQXKDv1j6 H9wa3TrvlSiXUZbllZOSAEtm17uzIyP7oPOgRWKP+qCPOebeqXhb0AWjApRIiHFze0DM 6ew8eMgO4143GCdiiWaNgNkxQZEjEzwzTN7YVPFs5KgYHIT3CC+BUZQSj+pkNdDtkOSs bFL4Tw3UAMoE7nN5ZBE4aSW0NHNpy8jnlVSrDnSX4u6CS7NUEDmLgC5ooghMd5zdfz5j T3UQ==
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=CmqzKP0T4T+l6RBtxGDaT8Y3wCnO7gw35hGfRraqPwk=; b=nDYSfz4D4BojUGkV8+8NbsYaC6+FTeYVZPiKipoqK9V+zK7OZyYGru2Ay+p5hKO+OV wD2WAb9DrkTmp3YzKHKpTDQJ7IXBuqizmaW3QO0FxXLG4LwIBYx8pn/gBH4hGzAdiuE5 tu95tWaNMQKRZCk6pMqiXCYbLJnp2GTiRHruoIU2DXccLcRyZt30PBeX+CROJdBvVw06 HSK5XBpsNSQFUTRNEZTlvS5XyAk4DRNZgI1qJPXshJEhQ5x3MKvDViub885o6WQ0gyZv kf/IHuCuuqavCxEfb+/5dmYRvJcR+HAh8JrbrfCzwxVCBO1aft/7StYeWpZu7y9jv+Pm 6yFA==
X-Gm-Message-State: AFeK/H2VgKwkEdYFvfKWEOgWe1TdxPf0koPshY7oSyulj2THqQF3ikdQ8ObrA5X3X+kpNRzAA7Zp12UUJKGT7Q==
X-Received: by 10.200.44.36 with SMTP id d33mr18462355qta.198.1490546248920; Sun, 26 Mar 2017 09:37:28 -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>
In-Reply-To: <9c814ef0-4df3-35ed-5453-dd8cad91b910@free.fr>
From: Nat Sakimura <sakimura@gmail.com>
Date: Sun, 26 Mar 2017 16:37:18 +0000
Message-ID: <CABzCy2AqK0rCRRZ1w_KXiKNbzjqwSx+OMS2nSXnfjLsuE-cgvg@mail.gmail.com>
To: Denis <denis.ietf@free.fr>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a1140298cb038ef054ba4d70a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Hkl5Bk_n11BCqUl_rwcLAFmbu4I>
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: Sun, 26 Mar 2017 16:37:34 -0000
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
- [OAUTH-WG] oauth - Requested sessions have been s… "IETF Secretariat"
- Re: [OAUTH-WG] oauth - Requested sessions have be… Mike Jones
- Re: [OAUTH-WG] oauth - Requested sessions have be… Brian Campbell
- Re: [OAUTH-WG] oauth - Requested sessions have be… Torsten Lodderstedt
- Re: [OAUTH-WG] oauth - Requested sessions have be… Antonio Sanso
- Re: [OAUTH-WG] oauth - Requested sessions have be… Nat Sakimura
- Re: [OAUTH-WG] oauth - Requested sessions have be… Denis
- Re: [OAUTH-WG] oauth - Requested sessions have be… Nat Sakimura
- Re: [OAUTH-WG] oauth - Requested sessions have be… Denis
- Re: [OAUTH-WG] oauth - Requested sessions have be… Nat Sakimura
- Re: [OAUTH-WG] oauth - Requested sessions have be… Denis
- Re: [OAUTH-WG] oauth - Requested sessions have be… Benjamin Kaduk
- Re: [OAUTH-WG] oauth - Requested sessions have be… Benjamin Kaduk