Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

Stephen Farrell <> Fri, 03 February 2012 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53A7721F856A; Fri, 3 Feb 2012 05:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hE7aKXORzqe0; Fri, 3 Feb 2012 05:17:53 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 1A12D21F8559; Fri, 3 Feb 2012 05:17:52 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD507171C25; Fri, 3 Feb 2012 13:17:51 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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
Received: from ([]) by localhost ( []) (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 (Postfix) with ESMTPSA id C3537171C06; Fri, 3 Feb 2012 13:17:50 +0000 (GMT)
Message-ID: <>
Date: Fri, 03 Feb 2012 13:17:41 +0000
From: Stephen Farrell <>
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 <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mike Jones <>, IETF-Discussion Discussion <>, General Area Review Team <>, "" <>, "" <>
Subject: Re: [Gen-art] [OAUTH-WG] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2012 13:17:54 -0000

That looks fine to me fwiw,

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