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

Alexey Melnikov <> Fri, 03 February 2012 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46D5A21F8625; Fri, 3 Feb 2012 05:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.099
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1wLe8FBT9DWy; Fri, 3 Feb 2012 05:14:20 -0800 (PST)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (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;; s=selector;; 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 [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 3 Feb 2012 13:14:17 +0000
Message-ID: <>
Date: Fri, 03 Feb 2012 13:14:25 +0000
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
To: Mike Jones <>, Stephen Farrell <>
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <>, "" <>, "" <>, IETF-Discussion Discussion <>
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: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)

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