Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

John Bradley <ve7jtb@ve7jtb.com> Sat, 09 November 2013 15:51 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 E82EE21E80D9 for <oauth@ietfa.amsl.com>; Sat, 9 Nov 2013 07:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.121
X-Spam-Level:
X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Ee+05+IpnSt4 for <oauth@ietfa.amsl.com>; Sat, 9 Nov 2013 07:51:35 -0800 (PST)
Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 357B211E8122 for <oauth@ietf.org>; Sat, 9 Nov 2013 07:51:35 -0800 (PST)
Received: by mail-pb0-f43.google.com with SMTP id md4so3396073pbc.16 for <oauth@ietf.org>; Sat, 09 Nov 2013 07:51:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LQbUsXxN8YkURCwCdP13UB8Ym79rbQabxACoL8kwQKg=; b=UgUBvRo9cd9uV5ieJnIrk02VZa2Bl+Bo6JkddpSRCYCcxSLHczJH8WgqkQFmPftPlR DQlGqvtvnMEbrifLrbMVMMLNK3eQYsRmHnd/OsCmvs/pE3OmHfqgV7VmXRXGI/pL2wPF Nk/sDEOIb+mrvOnp8a5V+zgLPJ9UixDW0WSQHqZjoqhGb9NtxEU85sGaju7TG8ZTs8mD 34GQEL3aT6cvTEw7FfzcwXCecc03kBrjFpixoI9aDy+UwgLRcnm4N5zjyrcN7ga1QVTr q5wIQI4fOUlVHn1BI+r0nWdYDZUlWUwxPi6eNDwfyTBupbXia/JEwhIvQYfUMVvxtJOQ x+3Q==
X-Gm-Message-State: ALoCoQmPYmfVSo7vwMevYFOP730AImcP6LikKMQuMLED6WO9BxjKVZILV2uuHAuEgLGM3KNNw54T
X-Received: by 10.66.26.110 with SMTP id k14mr1006456pag.171.1384012293794; Sat, 09 Nov 2013 07:51:33 -0800 (PST)
Received: from [192.168.6.17] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id sg1sm19353081pbb.16.2013.11.09.07.51.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Nov 2013 07:51:32 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_3419D318-587B-47FD-BBFF-221FBEC7A5F3"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <527E376C.2010205@lodderstedt.net>
Date: Sat, 09 Nov 2013 07:51:27 -0800
Message-Id: <001C64DB-2DD0-4740-8C9A-B7A0445F68CD@ve7jtb.com>
References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> <CABzCy2Ai6W3XRLzXTGQB8vS40V6QTsoa6Q+7uq4zMftgnZkc7g@mail.gmail.com> <527E376C.2010205@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.1822)
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.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: Sat, 09 Nov 2013 15:51:40 -0000

With a native app using a captive browser with no malware, only the response is susceptible to interception, making encrypting the request redundant.
In other environments and with some user groups the request's challenge needs to be protected from interception.  This may be more the case in a desktop environment where there is less control over the browser.

I expect that we will come to two options one unprotected requests and one for protected requests.

To Phil's point this is not about identifying the class of software this is about matching a response to an instance of software.   
A software statement gives you a hint about the class of software but not the instance without per client registration.

This method gives you the ability to securely return the token to only the instance of the client that requested it without the overhead of per instance dynamic registration.

This is a practical solution to a real problem people are having today, and versions of this are in production now.   

Nat and I are trying to document it so that there can be interoperability rather than every AS doing something different.

John B.

On Nov 9, 2013, at 5:23 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Hi Nat,
> 
> what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants.
> 
> regards,
> Torsten.
> 
> 
> Am 19.10.2013 12:15, schrieb Nat Sakimura:
>> Incorporated the discussion at Berlin meeting and after in the ML. 
>> 
>> Best, 
>> 
>> Nat
>> 
>> ---------- Forwarded message ----------
>> From: <internet-drafts@ietf.org>
>> Date: 2013/10/19
>> Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt
>> To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@pingidentity.com>, Naveen Agarwal <naa@google.com>
>> 
>> 
>> 
>> A new version of I-D, draft-sakimura-oauth-tcse-02.txt
>> has been successfully submitted by Nat Sakimura and posted to the
>> IETF repository.
>> 
>> Filename:        draft-sakimura-oauth-tcse
>> Revision:        02
>> Title:           OAuth Symmetric Proof of Posession for Code Extension
>> Creation date:   2013-10-19
>> Group:           Individual Submission
>> Number of pages: 8
>> URL:             http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt
>> Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
>> Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02
>> 
>> Abstract:
>>    The OAuth 2.0 public client utilizing authorization code grant is
>>    susceptible to the code interception attack.  This specification
>>    describe a mechanism that acts as a control against this threat.
>> 
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> 
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth