Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture-00

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 03 March 2015 14:20 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 E84181A86E2 for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 06:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Nthtz0zbfHKo for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 06:20:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2921A86DD for <oauth@ietf.org>; Tue, 3 Mar 2015 06:20:09 -0800 (PST)
Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4o41-1XYFi41MhZ-00z2fX; Tue, 03 Mar 2015 15:20:05 +0100
Message-ID: <54F5C313.3070507@gmx.net>
Date: Tue, 03 Mar 2015 15:20:03 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <913383AAA69FF945B8F946018B75898A2831D1E6@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2831D1E6@xmb-rcd-x10.cisco.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PsaAnk08ASoubXu4mdIjbV9CuSevTCevE"
X-Provags-ID: V03:K0:7+WRDLBZ4ziK6mPkaIBvPtF/5Ufk/Y3tXuvudcG5ZCLiGe4G1BH u8vtB0+NLF9NM9F+6DrPKxzqq+NJAcdr3e9RGkoVVsBeYImB8WmO/Eeq5D755o+cOI7gYLW YOBrpsvdTZzKbRMIP7TOBsPEsB91O67f0JVTNEHSSYU+HSLF13CxsoBXWNLxzzzmpRxdJgY Zj2Rg+ceGX78/OAJKsxBw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/N2hv1KuB3aJPzxsEdv3oy2wnBdY>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-pop-architecture-00
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: <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: Tue, 03 Mar 2015 14:20:14 -0000

Hi Reddy,

thanks a lot for your review comments and for failing to notice them.

On 08/28/2014 09:05 AM, Tirumaleswar Reddy (tireddy) wrote:
> My comments:
> 
>  
> 
> 1) Figure 3: Resource server in the response could also generate
> Signature/MAC to prove the client that it is in possession of
> cryptographic keying material.
> 

Correct. Added.

>  
> 
> 2) Section 3.2:
> 
> Will new HTTP headers be defined in one of the PoP drafts for the
> application layer to carry the TLS channel binding information ?

This is up to the solution.
> 
>  
> 
> 3)Section 3.3: It is covering various attack scenarios except active,
> man-in-middle attack.
> 

Section 3 discusses use cases. Section 3.3 describes a scenario where
TLS is not used and the need for an alternative security solution (other
than bearer arises).

I think an active man-in-the-middle use case would not be a good
suggestion ;-)


>  
> 
> 4)Why only discuss TLS and not DTLS ?

The members of the design team where this work came from focused on the
web. I agree that this work is equally applicable to the non-Web
environment (as the recent work in the ACE group had shown).

I would, however, leave it to the ACE working group to explore the use
of OAuth for IoT (with DTLS, CoAP, etc.), if there is enough interest.


> 
>  
> 
> 5)Section 3.4: Enterprise networks, ISP etc. may also deploy HTTP(S) proxy.
> 
Sentence added.

>  
> 
> 6)Please explain scenarios in which using asymmetric cryptography is
> better suited for PoP than using symmetric cryptography.

While symmetric cryptography provides better performance properties the
use of asymmetric cryptography allows the client to keep the private key
locally and never expose it to any other party. I would see this as a
strong security benefit that will more and more important in the future
as we see backend database systems hacked over and over again.


> 
>  
> 
> 7)I don’t see any discussion on HMAC algorithm negotiation b/w the
> client and resource server.
> 
>    It may help to define mandatory to implement and default algorithms.
> 
> 
I added a note about it.


> 
> 8)Protocols like Dynamic Symmetric Key Provisioning Protocol (DSKPP)
> (RFC6063) could be considered for long-term secret b/w the AS and RS.
> 
>  
DSKPP would indeed be a viable solution for distributing symmetric keys.

> 
> 9)Nit> Figure 4: Add arrows for (V) and (IV)
> 
Thanks. Fixed.


>  
> 
> 10)   AS-to-RS Relationship Anonymity:
> 
>  
> 
>       This MAC Token security does not provide AS-to-RS relationship
> 
>       anonymity since the client has to inform the resource server about
> 
>       the resource server it wants to talk to.
> 
> 
> 
> Nit> I think you meant “inform the authorization server about the
> resource server it wants to talk to”
> 

I changed this paragraph.

Thanks again for reading through the document so carefully.

Ciao
Hannes

>  
> 
> Cheers,
> 
> -Tiru
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>