Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 03 February 2012 13:14 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5A21F8625; Fri, 3 Feb 2012 05:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.099
X-Spam-Level:
X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wLe8FBT9DWy; Fri, 3 Feb 2012 05:14:20 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70E21F856D; Fri, 3 Feb 2012 05:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328274857; d=isode.com; s=selector; i=@isode.com; bh=p040+9qOAPW1BYfPD5JvCq4sWOPy7yNFjhEkpCArW6Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Jhds+fq1zgVGtDOykvZX7ojd9Hz51G15ZXla6PpoaXs456uWdvdo/OTl77qxMOrZs/9toH hgo90Dzu26awl06pNURGGIR6C9/wBf1FqRoSGLwSZva5O97JqsEsHTXBpjEYnFe+5FY6zL +izWzbQRGOcjxPG5h1xJy+tsM+jxuTg=;
Received: from [144.254.105.99] (dhcp-guest-bru-peg1-144-254-105-99.cisco.com [144.254.105.99]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TyvdpwAvKKUJ@rufus.isode.com>; Fri, 3 Feb 2012 13:14:17 +0000
Message-ID: <4F2BDDB1.8030709@isode.com>
Date: Fri, 03 Feb 2012 13:14:25 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
To: Mike Jones <Michael.Jones@microsoft.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com>
In-Reply-To: <4F27C37C.1090008@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <gen-art@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>
Subject: Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2012 13:14:21 -0000
On 31/01/2012 10:33, Alexey Melnikov wrote: > On 30/01/2012 05:20, Mike Jones wrote: [...] >> About your third minor issue on RFC 6125 versus RFC 2818, you'll find >> that, per the history entries, a previous reference to RFC 2818 was >> changed to RFC 6125 in draft 14 at the request of Security Area >> Director Stephen Farrell. I've quickly chatted with Stephen and he said that he only asked the question and didn't necessarily instructed the WG to do the change from RFC 2818 to RFC 6125. Keeping this in mind... >> If you'd like to see this reference reintroduced, I'd request that >> you work with Stephen on specific alternative proposed wording that >> is acceptable to both of you. > Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 > co-author) on some text. So, here are the proposed changes: 4.2. Threat Mitigation To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] with a ciphersuite that provides confidentiality and integrity protection. This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection. Since TLS is mandatory to implement and to use with this specification, it is the preferred approach for preventing token disclosure via the communication channel. For those cases where the client is prevented from observing the contents of the token, token encryption MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources. I suggest inserting "[RFC5280]" at the end of the last sentence above. To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact of them being leaked. Second, confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied. As a consequence, no eavesdropper along the communication path is able to observe the token exchange. Consequently, such an on-path adversary cannot replay the token. Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125]. Please replace the last sentence quoted above with: Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per section 3.1 of [RFC2818]. [Expanded motivation for the change: I think the reference to RFC 6125 needs to be replaced with the reference to section 3.1 of RFC 2818. Firstly, the procedure described in RFC 6125 differs slightly from RFC 2818 (matching of IP addresses is allowed, wildcards can be used with partial hostnames (e.g. foo* is allowed, where RFC 6125 doesn't allow for that). Secondly, if RFC 6125 is referenced, then the OAuth document needs to say whether SRV-ID/URI-IDs are allowed and whether wildcards are allowed.]
- [Gen-art] Gen-ART review of draft-ietf-oauth-v2-b… Alexey Melnikov
- Re: [Gen-art] Gen-ART review of draft-ietf-oauth-… Mike Jones
- Re: [Gen-art] Gen-ART review of draft-ietf-oauth-… Alexey Melnikov
- Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-… Alexey Melnikov
- Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-… Stephen Farrell
- Re: [Gen-art] Gen-ART review of draft-ietf-oauth-… Alexey Melnikov
- [Gen-art] Gen-ART Telechat review of draft-ietf-o… Alexey Melnikov
- [Gen-art] where do error codes go?, was: [OAUTH-W… Julian Reschke
- [Gen-art] Gen-ART Telechat review of draft-ietf-o… Alexey Melnikov
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Stephen Farrell
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Mike Jones
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Julian Reschke
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Alexey Melnikov
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Mike Jones
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Julian Reschke
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Mike Jones
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Julian Reschke
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Mike Jones
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Alexey Melnikov
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Julian Reschke
- Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review … Julian Reschke