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: Anthony Nadalin
Sent: Thursday, March 05, 2015 10:11 AM
To: Mike Jones; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open
Issues before the Deadline
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; oauth@ietf.org
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open
Issues before the Deadline
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:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, March 04, 2015 3:26 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open
Issues before the Deadline
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:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
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:
"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
_______________________________________________
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
