Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

John Bradley <ve7jtb@ve7jtb.com> Wed, 04 March 2015 22:01 UTC

Return-Path: <ve7jtb@ve7jtb.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 D4DAA1A893E for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 14:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pv_d8I6fEmUh for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 14:01:17 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (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 1F1351A8978 for <oauth@ietf.org>; Wed, 4 Mar 2015 14:01:17 -0800 (PST)
Received: by wesx3 with SMTP id x3so2621221wes.4 for <oauth@ietf.org>; Wed, 04 Mar 2015 14:01:15 -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=FxmNvvAR56zYS07PgvNZzpueiEX4qD+yJ6q3xXEb7Sg=; b=TpDO2p7atd9ZdULxcY4E5e+qXUPnTuh9uBh8y9Vf6PRlstrmV43NqFI7szXyJYBM5F GRfwRM83HWNC0H6CdJTx+sdjwR/NkBje1x8SAAmEs6sEld/wLmq3tf2iOuyjmwXkYfzd pdZtZkcxcCKGeMmkuQaRRuRAexhHvGcuj9GVsMq23ldV3e+dd0mRzX93ev8XrV0mFlxr GEwG4zf3D9dqVi13TbE/LI18Bg40cMUHFtCD2/m0ATfLx+Wy8toP810Dwe0IS7GEFMzP SiMgTRCZJUijNgURtCMXw0/zi9TekuHZtnUi/s07XAuxUqzatW+G1fBjdouyREDU0NV1 YJeg==
X-Gm-Message-State: ALoCoQkv0ACmNPZv7bU4V5K5JGrb7pgn7RHDraRAmjDIhq8MTkr4/JwtMselqhJuyUire6hJRLtc
X-Received: by 10.194.9.98 with SMTP id y2mr12465283wja.85.1425506475798; Wed, 04 Mar 2015 14:01:15 -0800 (PST)
Received: from [10.6.0.13] ([95.211.146.166]) by mx.google.com with ESMTPSA id hi6sm7705662wjc.34.2015.03.04.14.01.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 14:01:14 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_DF7D6C50-4B5E-48F4-AF27-850D3066D48A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54F71978.5090804@gmx.net>
Date: Wed, 4 Mar 2015 23:01:14 +0100
Message-Id: <D413222C-BF96-4EC1-8B13-70A135D4D6AB@ve7jtb.com>
References: <54F71978.5090804@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/TkLF7BDrcFvaSofmwzipvjo1M4A>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
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: Wed, 04 Mar 2015 22:01:20 -0000

> On Mar 4, 2015, at 3:40 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> Hi all,
> 
> as the deadline is approaching I would like to close the open issues of
> the document. There are two open issues listed in the document and I
> propose ways to resolve them below
> 
> Open Issue #1:
> 
> "In some conversations, we have said that it is the issuer of the JWT
> that possesses the key, and in some conversations, we have said that
> it is the presenter of the JWT that possesses the key.  Which
> description should we use?
> "

> The presenter 
> There are the following parties in the entire picture (as the PoP
> architecture document illustrates quite nicely):
> 
> * Issuer: Party that creates the JWT and binds a key to the token.
> The key may be a symmetric key or a public key. To bind the key to the
> JWT the issuer needs to compute a digital signature or a keyed message
> digest over the JWT.
> 
> * Presenter: Party that demonstrates possession of a private key (for
> asymmetric key cryptography) and secret key (for symmetric key
> cryptography) to a recipient.
> 
> * Recipient: Party that receives the JWT together with the proof of
> possession of the key (typically in form of a digital signature or a
> keyed message digest).
> 
> Mapping this terminology to the OAuth context would look as follows:
> - Issuer: OAuth Authorization Server
> - Presenter: OAuth Client
> - Recipient: OAuth Resource Server
> 
> Adding the above-mentioned terminology to the terminology section (and
> deleting the currently listed presenter) would resolve the issue IMHO.
> 
That looks OK

> Open Issue#2:
> 
> Mike added an editorial note to the introduction saying:
> "
> [[ Editorial Note: This paragraph needs to be updated to provide more
> context and possibly also to describe the use of asymmetric keys
> instead.  It's not clear that the symmetric case is as useful or
> valuable, and it is certainly more complicated.]]
> "
> 
> The design team work clearly indicated that both symmetric and
> asymmetric cryptography has to be supported. The JWT mechanism actually
> supports both and hence we should also describe both. What can, however,
> be done is to also describe the asymmetric key case and here is my text
> proposal for the introduction.
> 

Agreed we need both.
> ----
> 1.  Introduction
> 
> This specification defines how to bind a key to a JSON Web
> Token (JWT) [JWT]. Three parties act in such a scenario:
> 
> * Issuer: Party that creates the JWT and binds a key to the token.
> The key may be a symmetric key or a public key. To bind the key to
> the JWT the issuer needs to compute a digital signature or a keyed
> message digest over the JWT.
> 
> * Presenter: Party that demonstrates possession of a private key
> (for asymmetric key cryptography) and secret key (for symmetric
> key cryptography) to a recipient. This property is also sometimes
> described as the presenter being a holder-of-key.
> 
> * Recipient: Party that receives the JWT together with the proof of
> possession of the key (typically in form of a digital signature or a
> keyed message digest).
> 
> [I-D.ietf-oauth-pop-architecture] describes the use of
> proof-of-possession semantics for JSON Web Tokens (JWTs) for the use
> with OAuth.
> 
> Envision the following two use cases. The first use case describes
> the use of a symmetric key and the second use case focuses on
> asymmetric cryptography.
> 
> An OAuth 2.0 authorization server generates a JWT
> and places an encrypted symmetric key inside the newly introduced
> confirmation claim.  This symmetric key is encrypted with a key known
> only to the authorization server and the recipient. The entire JWT
> is then integrity protected.  The JWT is then sent to the
> presenter.  Since the presenter is unable to obtain the
> encrypted symmetric key from the JWT itself, the authorization
> server conveys that symmetric key separately to the presenter.  Now,
> the presenter is in possession of the symmetric key as well as the
> JWT (which includes the confirmation claim member).  When the
> presenter needs to present the JWT to the recipient, it also needs
> to demonstrate possession of the symmetric key; the presenter, for
> example, uses the symmetric key in a challenge/response protocol
> with the recipient.  The recipient is able to verify that it is
> interacting with the genuine presenter by decrypting the JWK
> contained inside the confirmation claim of the JWT.  By doing this
> the recipient obtains the symmetric key, which it then uses to
> verify cryptographically protected messages exchanged with the
> presenter.
> 
> This symmetric key mechanism described above is conceptually similar
> to the use of Kerberos tickets.
> 
> In the second case consider a presenter that generates a public /
> private key pair. It then sends the public key to an OAuth 2.0
> authorization server, which creates a JWT and places an public key
> (or a fingerprint of it) inside the newly introduced confirmation
> claim. The entire JWT is then integrity protected using a digital
> signature to protect it against modifications.
> 
> The JWT is then sent to the presenter. When the presenter needs to
> present the JWT to the recipient, it also needs to demonstrate
> possession of the private key. The presenter, for example, uses the
> private key in TLS exchange with the recipient.  The recipient
> is able to verify that it is interacting with the genuine presenter
> by extracting the public key from the confirmation claim of the
> JWT (after verifying the digital signature of the JWT) and utilizing
> it with the private key in the TLS exchange.
> 
> The asymmetric key mechanism described above is conceptually similar
> to a certificate.
> 
> In both cases the JWT may contain various claims that are included
> based on the policy of the authorization server.
> 

In the asymmetric case if the client has a secure element having it generate the key and send the keys 
and sending public  key to the AS is more secure than having the AS generate it.

We support both ways.  I suppose it is OK to mention only one in the introduction.

I will spend some time on it now that MWC is almost over.

John B.
> ----
> 
> Due to the IETF draft submission deadline we would appreciate a response
> by next Sunday.
> 
> Ciao
> Hannes
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth