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.]
>
>