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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 15:40:56 +0100

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?
"

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.

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.

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

----

Due to the IETF draft submission deadline we would appreciate a response
by next Sunday.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 4 Mar 2015 23:01:14 +0100

> On Mar 4, 2015, at 3:40 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 

> The presenter 
That looks OK

> proposal for the introduction.

Agreed we need both.
> 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.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 4 Mar 2015 23:25:50 +0000

Why does the specification state "encrypted to a key known to the recipient using the JWE Compact Serialization" is this the only serialization allowed (there is no MUST) ?
containing the symmetric key.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

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:

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

Adding the above-mentioned terminology to the terminology section (and deleting the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

   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.

----
1.  Introduction

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

----

Due to the IETF draft submission deadline we would appreciate a response by next Sunday.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Wed, 4 Mar 2015 23:33:51 +0000

It does so for the same reason that the JWT spec does - to promote interoperability.  We can add wording along the likes of "the JWE Compact Serialization MUST be used" if you like.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Hi all,

Open Issue #1:

Open Issue#2:

----
1.  Introduction

----

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 5 Mar 2015 18:11:03 +0000

This can't be limited to JWE Compact Serialization, we have keys that use the JSON binary serialization.

"cnf" seems underspecified, as this could be a JWK (but not it's not a MUST), and thus I may understand "cnf" but only when used with a JWK and not some other invented structure. So how do I tell what "cnf" really is ?

Is this proposal also limited to a single key  for both asymmetric and symmetric  ?

-----Original Message-----
From: Mike Jones 
Sent: Wednesday, March 4, 2015 3:34 PM
To: Anthony Nadalin; Hannes Tschofenig; [email-masked]
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Hi all,

Open Issue #1:

Open Issue#2:

----
1.  Introduction

----

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Mar 2015 18:47:51 +0000

Per https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-01#section-3.1, keys can be represented as JWKs (which are JSON objects), so I think the draft already does what you're asking for in that regard.  If that's not what you're asking for, maybe we can talk about it in person and determine what actions to propose.

The "cnf" syntax is based on existing practice as already in production use by XBOX One and its partners.  That in turn was loosely based on the SAML SubjectConfirmation element - existing semantic practice that we tried to follow for JWTs.

Sure, applications can specify ways of sending lots of keys, including proof-of-possession keys, and different keys for different purposes.  They'd probably define claims with application-specific meanings to do that, which is fine.  This spec is trying to cover the common case, where a single subject conformation key is used for a particular security token.  Having the common case covered doesn't take away the ability to do more complicated application-specific things, if needed.

				-- Mike

-----Original Message-----
From: Mike Jones 
Sent: Wednesday, March 4, 2015 3:34 PM
To: Anthony Nadalin; Hannes Tschofenig; [email-masked]
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: [email-masked]
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Hi all,

Open Issue #1:

Open Issue#2:

----
1.  Introduction

----

Ciao
Hannes