Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

Anthony Nadalin <tonynad@microsoft.com> Mon, 07 April 2014 01:46 UTC

Return-Path: <tonynad@microsoft.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 752D01A063B for <oauth@ietfa.amsl.com>; Sun, 6 Apr 2014 18:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 2JR_Vf2pvecS for <oauth@ietfa.amsl.com>; Sun, 6 Apr 2014 18:46:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id D004A1A01F0 for <oauth@ietf.org>; Sun, 6 Apr 2014 18:46:02 -0700 (PDT)
Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 7 Apr 2014 01:45:55 +0000
Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0918.000; Mon, 7 Apr 2014 01:45:55 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>, John Bradley <ve7jtb@ve7jtb.com>, Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt
Thread-Index: AQHPT1ol/WlOVQaWcUeFKb0tHOmcZJsAF2eAgAABEICAABi7AIAABhAAgAUvlGA=
Date: Mon, 07 Apr 2014 01:45:54 +0000
Message-ID: <5eb59ad6654c4e38adb85afba06bbc8b@BLUPR03MB309.namprd03.prod.outlook.com>
References: <20140403083747.31162.58961.idtracker@ietfa.amsl.com> <1396541184.357.YahooMailNeo@web125601.mail.ne1.yahoo.com> <533D8CA3.6070005@oracle.com> <533D8E5F.8000600@redhat.com> <6BE94541-2DAA-4CDA-8478-E1BF99480629@oracle.com> <A3F617B5-BD1F-4A8F-8A46-2DD5D0FBF4F8@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439A139FC3@TK5EX14MBXC286.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A139FC3@TK5EX14MBXC286.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2404:1a0:1001:16:f0c2:abde:79ae:5539]
x-forefront-prvs: 0174BD4BDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(479174003)(24454002)(377454003)(189002)(199002)(377424004)(74662001)(90146001)(74502001)(47446002)(15395725003)(16236675002)(81342001)(31966008)(81816001)(93136001)(81686001)(92566001)(93516002)(81542001)(74366001)(74706001)(85852003)(83072002)(74876001)(76576001)(86362001)(76796001)(76786001)(69226001)(14971765001)(56816005)(94316002)(97186001)(80976001)(97336001)(94946001)(74316001)(59766001)(19609705001)(77982001)(19580395003)(83322001)(19580405001)(33646001)(16799955002)(87266001)(87936001)(2656002)(20776003)(19300405004)(63696002)(15188155005)(80022001)(65816001)(79102001)(15975445006)(95416001)(53806001)(54356001)(46102001)(1511001)(99396002)(85306002)(56776001)(54316002)(50986001)(47976001)(49866001)(47736001)(76482001)(98676001)(15202345003)(4396001)(95666003)(42262001)(24736002)(3826001)(19623215001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:A84FFD3D.ACF677CC.B7C37F49.52E4C9B1.204AA; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_5eb59ad6654c4e38adb85afba06bbc8bBLUPR03MB309namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/J9AIf_BfB8qgKZPewUIQP1P4ffA
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.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: <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: Mon, 07 Apr 2014 01:46:07 -0000

I have to agree with Phil on this as there are already spec out there that use HoK and PoP , either of these work but prefer HoK as folks get confused with PoP as we have seen this within our company already

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, April 3, 2014 11:32 AM
To: John Bradley; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

I agree with what John wrote below.  Besides, PoP is more natural to say than HoK and certainly more natural to say than HOTK.  I'd like us to stay with the term Proof-of-Possession (PoP).

                                                            -- Mike

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, April 03, 2014 11:10 AM
To: Phil Hunt
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

Some people and specs associate holder of key with asymmetric keys.  Proof of possession is thought to be a broader category including symmetric and key agreement eg http://tools.ietf.org/html/rfc2875.

NIST defines the term PoP Protocol http://fismapedia.org/index.php?title=Term:Proof_of_Possession_Protocol

In SAML the saml:SubjectConfirmation method  is called urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

In WS* the term proof of possession is more common.

So I think for this document as an overview "Proof of Possession (PoP) Architecture" is fine.

John B.

On Apr 3, 2014, at 12:41 PM, Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote:

What was wrong with HOK?

Aside: Why was "the" so important in HOTK?

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On Apr 3, 2014, at 9:37 AM, Anil Saldhana <Anil.Saldhana@redhat.com<mailto:Anil.Saldhana@redhat.com>> wrote:

Prateek,
  why not just use "proof"?

draft-hunt-oauth-proof-architecture-00.txt

Is that allowed by IETF?


Regards,
Anil

On 04/03/2014 11:30 AM, Prateek Mishra wrote:
"key confirmed" or "key confirmation" is another term that is widely used for these use-cases
I really *like* the name "proof of possession", but I think the acronym PoP is going to be confused with POP.  HOTK has the advantage of not being a homonym for aything else.  What about "Possession Proof"?

-bill
--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!

On Thursday, April 3, 2014 1:38 AM, "internet-drafts@ietf.org"<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org><mailto:internet-drafts@ietf.org> wrote:

A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt
has been successfully submitted by Hannes Tschofenig and posted to the
IETF repository.

Name:        draft-hunt-oauth-pop-architecture
Revision:    00
Title:        OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
Document date:    2014-04-03
Group:        Individual Submission
Pages:        21
URL:            http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt
Status:        https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
Htmlized:      http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00


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




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<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth