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