Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 25 November 2015 20:39 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9227C1B2F7D for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 12:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QDJnXgMvc0u for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 12:39:22 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E521A8919 for <oauth@ietf.org>; Wed, 25 Nov 2015 12:39:19 -0800 (PST)
Received: by qgcc31 with SMTP id c31so40891669qgc.3 for <oauth@ietf.org>; Wed, 25 Nov 2015 12:39:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcA6Q5Qjkus2Vv8W9eTBskyFKkKl74e7ocMX+Q4TL54=; b=lyUE+baEjgoyxcFfj7oNRAzKbcB4k8FqZfLqwyucSHnmh3s7/9toY9Xt2gtUg2Nf80 BGX2Bm2i4hFJ4a7yD+0fQdBNjbOm2brREF/790ckjw8L80/DpnYxEL39ag2A83e2F1fV z0cJnLCsZapMWf55Ld0XHZjVDe+HW5Pe6tLmhj2GSCaQaT7An08ZH6Fvq/oDiAqfs742 ZouKkgWiq3JlSMGWmSSG0JVfK7k9AoEX3qdtEFmIMXYBkYMXfDRtgfwB/XZrAasaYsMj sqk+18EEScwP22nZ61FBe3BwNlNssAVFPtFyDF0AB1mYmxN3+WD7lqHQy5tx38Yzi/wK xabA==
X-Received: by 10.140.89.113 with SMTP id u104mr36073349qgd.98.1448483958710; Wed, 25 Nov 2015 12:39:18 -0800 (PST)
Received: from [10.60.76.50] (mobile-107-107-57-11.mycingular.net. [107.107.57.11]) by smtp.gmail.com with ESMTPSA id 31sm5997012qgy.13.2015.11.25.12.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Nov 2015 12:39:17 -0800 (PST)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-BDE9C893-E631-447F-8357-0A960F41AA42"
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com>
Date: Wed, 25 Nov 2015 15:39:14 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <7431079B-818C-46E9-8102-D193E49384B2@gmail.com>
References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <F787FB76-5C8D-45F5-8A81-E430E75A0455@oracle.com> <CA+k3eCSeOyc2HMY+sK9rSjxkSAvNPWqwKyJNjDZAaCu2Stqk=w@mail.gmail.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <CA+k3eCT1+=2zysgbaKEmWCkQmsKyjr9KbghgmOVYUSC1qLfjbg@mail.gmail.com> <D8D36156-8BA6-43C5-8016-94A4CAE5FB45@mit.edu> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <CA+k3eCSJPCnawTjbByPcj+mmcK+vvQ_0Cxzs=24kT-irGETi7w@mail.gmail.com> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <EABBA496-7916-413A-BFE7-65BD03528F01@mit.edu> <CAD8AAD1-5A94-4F78-86EC-4D0F6FF6E0FE@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/U9twW3RO_zjIQq2YLS4txvIogQM>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 25 Nov 2015 20:39:27 -0000

Hi,

Sent from my iPhone

> On Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> Tokens are signed or the information is otherwise integrity protected between the AS and the RS.  
> 
> I suspect Kathleen is concerned about the key getting modified in transit.   
> That needs to be protected against, but there is more than one way to do that.

Phil is correct.  I was looking for consistency between the sections since they related to each other.  If there is a security risk or consideration, that needs to be explicitly called out as a concern such as a key being modified in transit.  If there are options to protect against that, those would ideally be required or would have warnings.
> 
> So sending the public key in a unsigned JWT access token would be immensely stupid,  not just for PoP but for scopes and everything else.

Good, easy to require then.

Thanks,
Kathleen 
> 
> In OAuth 2 all tokens need to be integrity protected between the AS and RS.  
> That can be via signature,  by having a reference with sufficient entropy and secure introspection or database lookup.
> 
> I think that is a OAuth 2 security consideration.   We are adding a additional confirmation claim to the existing information that needs to be protected the same as the rest.
> 
> John B.
> 
> 
>> On Nov 25, 2015, at 4:38 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> 
>> <editors hat>
>> If there is agreement that tokens are opaque then the requirement that tokens be signed must be removed from the threat mitigation requirements. 
>> 
>> And the paragraph in sec 5 that brian was concerned about be restored. 
>> 
>> Phil
>> 
>>> On Nov 25, 2015, at 11:24, Justin Richer <jricher@mit.edu> wrote:
>>> 
>>> It is still end to end authentication with opaque tokens — since all OAuth tokens, including PoP tokens, have always been intended to be opaque to the client. That hasn’t changed and that isn’t the intent of this document. If that’s how people are reading it then we need to pull it back and rewrite it so that’s not the case.
>>> 
>>> The client gets a token that has two parts: the token and the key. The token is analogous to the access_token we have today and would come out of the server in the same field. The key is handed to the client alongside the token or registered by the client during the token request. Either way there’s an association between the two but it’s not the same association as a public/private keypair. 
>>> 
>>> It’s possible to sign the token itself, but the client doesn’t care. It sends the token and signs the HTTP request to the RS whether the token is signed, unsigned, hex blob, encrypted, or anything else. The same series of options are available as with bearer tokens. PoP tokens have never, ever been intended to be anything but opaque to the client.
>>> 
>>> The token can’t be opaque to the RS, which has to figure out what key to use to check the message signature. But we’ve got options there, like the embedded key in a JWT from Mike’s draft, or doing introspection to get the key (from an extension that hasn’t been written yet), or simply looking it up in the same database because the RS and the AS are in the same box. Does this structure/service/database choice sound familiar? It should, it’s the same as bearer tokens. This is also how the RS gets information like which scopes are associated with the token, if it’s expired, and all that. 
>>> 
>>> 
>>> 
>>> 
>>> So here’s how I see it going on the wire:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> (I just wrote this up so there are probably holes. Here’s the source if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue )
>>> 
>>> The client is oblivious to the token just like always. This is intentional. The RS has the same options to figure out how to process the token.
>>> 
>>>  — Justin
>>> 
>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>> 
>>>> Folks, 
>>>> 
>>>> <editor hat>
>>>> I did not want to go here either. :-)
>>>> 
>>>> I don’t read sec 6 as examples.  I believe this may stem from the pop-architecture documents having a dual role as both “architecture” and “use-case”.  Maybe we should clarify the purpose of the document?
>>>> 
>>>> I believe section 6 is talking about threat mitigation assumptions based on the examples that need to be implemented.  I am assuming these are requirements that the other specifications SHOULD implement.
>>>> 
>>>> <personal hat>
>>>> I do not believe we have discussed Opaque PoP tokens and any inherent risks because the client is not or is unable to validate the authenticity of the token.  Does this introduce the possibility of a MITM attack where a client can be convinced to sign requests for an attacker?
>>>> 
>>>> If we want to include opaque PoP, I think we need to take a pause and consider / discuss any threats here.
>>>> 
>>>> I find the desire for opaque PoP tokens to be a bit contradictory. If we’re saying we don’t want to trust TLS alone (e.g. because of load-balancer termination), why would we then say, but we are perfectly willing to accept it worked for the OAuth AS exchanges?  Maybe I was very wrong here, but my assumption all along is that for PoP we’re talking about end-to-end authentication of all parties except in the case of 3.3 where we simply want to protect an access token over a non-TLS HTTP connection.
>>>> 
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>> 
>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>>>>> 
>>>>> While I can't say I disagree with the deeper existential questions about the draft that Justin raises, I was trying not to go there and rather just point out concerns with the newly added text. 
>>>>> 
>>>>> The text Phil cites from Sec 6 doesn't say the client must be able to parse and verify the token. It's an assumption to simplify the examples that follow and still the token is opaque to the client. I reread the whole draft (reluctantly) and there's nothing that says the token has to be non-opaque to the client. And it does talk about reference style tokens and encrypted tokens, both of which rely on the opaqueness to the client. 
>>>>> 
>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wrote:
>>>>>> Right, I read that as text for describing the examples and not for describing requirements.
>>>>>> 
>>>>>> The token itself doesn’t have to be signed at all.
>>>>>> 
>>>>>>  — Justin
>>>>>> 
>>>>>>> On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>>>>> 
>>>>>>> Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.…
>>>>>>> 
>>>>>>>    To simplify the subsequent description we assume in the PoP architecture
>>>>>>>    that the token itself is digitally signed by the authorization server
>>>>>>>    and therefore cannot be modified.
>>>>>>> 
>>>>>>> Please 
>>>>>>> Phil
>>>>>>> 
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com
>>>>>>> 
>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:
>>>>>>>> 
>>>>>>>> The token doesn’t have to be signed and the client doesn’t have to verify the signature on the token. That’s not PoP. The request has to be signed in a way that includes the token. The token itself can still be opaque. The *key* material can’t be opaque to the client, but the *token* material still is.
>>>>>>>> 
>>>>>>>> I agree with Brian that this statement is misleading.
>>>>>>>> 
>>>>>>>> The examples use a signed token but that is absolutely not a requirement. Maybe the examples shouldn’t all use one style.
>>>>>>>> 
>>>>>>>> What’s most difficult about this particular spec is that it’s very hand-wavy, saying “this is kinda a thing that kinda works like this” without saying how to actually do it. I’m honestly not sure it’s worth publishing as an RFC in its own right but I’m not going to stand in its way.
>>>>>>>> 
>>>>>>>>  — Justin
>>>>>>>> 
>>>>>>>>> On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>>>>>>>>> 
>>>>>>>>> Where does it say that? 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>>>>>>>> Except that later on we require the token be signed and the client verify that signed token. IOW mutual pop. 
>>>>>>>>>> 
>>>>>>>>>> Phil
>>>>>>>>>> 
>>>>>>>>>>> On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Looking at the diff I noticed the following new text, which seems to conflate bearer/PoP and opaqueness to the client. A client demonstrating proof-of-possession of some key is orthogonal to the client being able to parse and understand the access token itself. 
>>>>>>>>>>>  
>>>>>>>>>>> "In contrast to bearer tokens [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, this specification defines the requirements for proof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and relying parties."
>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>>>>>>>>>> This draft addresses review comments from Kathleen and Erik raised since the last draft.
>>>>>>>>>>>> 
>>>>>>>>>>>> It may not include some of the discussion from yesterday/today.  I will add that as the group decides.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> 
>>>>>>>>>>>> Phil
>>>>>>>>>>>> 
>>>>>>>>>>>> @independentid
>>>>>>>>>>>> www.independentid.com
>>>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>>>> 
>>>>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>>>>>> > This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>>>>>>>>>>>> >
>>>>>>>>>>>> >        Title           : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>>>>>>>>>>>> >        Authors         : Phil Hunt
>>>>>>>>>>>> >                          Justin Richer
>>>>>>>>>>>> >                          William Mills
>>>>>>>>>>>> >                          Prateek Mishra
>>>>>>>>>>>> >                          Hannes Tschofenig
>>>>>>>>>>>> >       Filename        : draft-ietf-oauth-pop-architecture-06.txt
>>>>>>>>>>>> >       Pages           : 23
>>>>>>>>>>>> >       Date            : 2015-11-24
>>>>>>>>>>>> >
>>>>>>>>>>>> > Abstract:
>>>>>>>>>>>> >   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
>>>>>>>>>>>> >   allows any party in possession of a bearer token (a "bearer") to get
>>>>>>>>>>>> >   access to the associated resources (without demonstrating possession
>>>>>>>>>>>> >   of a cryptographic key).  To prevent misuse, bearer tokens must be
>>>>>>>>>>>> >   protected from disclosure in transit and at rest.
>>>>>>>>>>>> >
>>>>>>>>>>>> >   Some scenarios demand additional security protection whereby a client
>>>>>>>>>>>> >   needs to demonstrate possession of cryptographic keying material when
>>>>>>>>>>>> >   accessing a protected resource.  This document motivates the
>>>>>>>>>>>> >   development of the OAuth 2.0 proof-of-possession security mechanism.
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > The IETF datatracker status page for this draft is:
>>>>>>>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>>>>>>>>>>>> >
>>>>>>>>>>>> > There's also a htmlized version available at:
>>>>>>>>>>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06
>>>>>>>>>>>> >
>>>>>>>>>>>> > A diff from the previous version is available at:
>>>>>>>>>>>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > 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.
>>>>>>>>>>>> >
>>>>>>>>>>>> > Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>>>>> > ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>>>>> >
>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>> > 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
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>>  				
>>>>>>>>>>> Brian Campbell
>>>>>>>>>>> Distinguished Engineer
>>>>>>>>>>> Ping Identity
>>>>>>>>>>> @	bcampbell@pingidentity.com
>>>>>>>>>>> 	+1 720.317.2061
>>>>>>>>>>> 	@pingidentity
>>>>>>>>>>> Connect with us!
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>                 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>>  				
>>>>>>>>> Brian Campbell
>>>>>>>>> Distinguished Engineer
>>>>>>>>> Ping Identity
>>>>>>>>> @	bcampbell@pingidentity.com
>>>>>>>>> 	+1 720.317.2061
>>>>>>>>> 	@pingidentity
>>>>>>>>> Connect with us!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>                 
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>>  				
>>>>> Brian Campbell
>>>>> Distinguished Engineer
>>>>> Ping Identity
>>>>> @	bcampbell@pingidentity.com
>>>>> 	+1 720.317.2061
>>>>> 	@pingidentity
>>>>> Connect with us!
>>>>> 
>>>>> 
>>>>>                 
>> _______________________________________________
>> 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