Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 03 February 2012 13:17 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 53A7721F856A; Fri, 3 Feb 2012 05:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 hE7aKXORzqe0; Fri, 3 Feb 2012 05:17:53 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12D21F8559; Fri, 3 Feb 2012 05:17:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD507171C25; Fri, 3 Feb 2012 13:17:51 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328275071; bh=rCgo3aUfHyU0P3 j7PcJYxpIPsDcKFJXdpbM26as6Ppw=; b=YJIRE6iyfjwsolXos24jUKGEwv6qRf mVO2dOuqU/1OXTPfZviMP1OxLA7bxFdJLzfLOqh7qKmjawKuSSZfHcwPZABidHnh 6RYTi88X0vHVflGodBqSdZndrK+o2EtAbjGuuV7QNzoS0RwxTuLX8ADFo0/3Ns4B EhMbXl7w3/WamgqGdjH9NqiBxEXPVRniemdh2l3WUv7DztunB23bHp2JPFBBLFZh YajHxpspA5oxVvigPinKf6vqgBlEBCEapMOnNhHzzFUNa/a9pRWtVRzu8AMSeHX5 ffg5kMJhwf6A/QRgMZ+T33J9z/MVfZUMGu14BwerXhH/6/wP85N/QgcQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 6BKpEOxwmkm1; Fri, 3 Feb 2012 13:17:51 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C3537171C06; Fri, 3 Feb 2012 13:17:50 +0000 (GMT)
Message-ID: <4F2BDE75.4080405@cs.tcd.ie>
Date: Fri, 03 Feb 2012 13:17:41 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com> <4F2BDDB1.8030709@isode.com>
In-Reply-To: <4F2BDDB1.8030709@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF-Discussion Discussion <ietf@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 03 Feb 2012 13:17:54 -0000
That looks fine to me fwiw, Thanks, S. On 02/03/2012 01:14 PM, Alexey Melnikov wrote: > 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.] > >
- Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth… Mike Jones
- Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth… Alexey Melnikov
- Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth… Alexey Melnikov
- Re: [OAUTH-WG] Gen-ART review of draft-ietf-oauth… Stephen Farrell
- Re: [OAUTH-WG] [Gen-art] Gen-ART review of draft-… Alexey Melnikov
- [OAUTH-WG] Gen-ART Telechat review of draft-ietf-… Alexey Melnikov
- Re: [OAUTH-WG] Gen-ART Telechat review of draft-i… Justin Richer
- [OAUTH-WG] where do error codes go?, was: Gen-ART… Julian Reschke
- [OAUTH-WG] Gen-ART Telechat review of draft-ietf-… Alexey Melnikov
- Re: [OAUTH-WG] Gen-ART Telechat review of draft-i… Stephen Farrell
- Re: [OAUTH-WG] Gen-ART Telechat review of draft-i… Mike Jones
- Re: [OAUTH-WG] Gen-ART Telechat review of draft-i… Julian Reschke
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Alexey Melnikov
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Mike Jones
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Julian Reschke
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Mike Jones
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Julian Reschke
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Mike Jones
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Alexey Melnikov
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Julian Reschke
- Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review … Julian Reschke