Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs)

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 12 Jun 2017 20:19:15 +0200

Hi all,

RFC 7800 defines how to communicate Proof of Possession (PoP) keys for
JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT)
draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of
the JSON/JOSE JWT spec.

The ACE working group is planning to also define a CBOR/COSE equivalent
of RFC 7800 and is interested in knowing how you might use CBOR
proof-of-possession keys for CWTs.

Please drop us a message if you are using CBOR PoP keys for CWTs. We
would like to learn more about your usage.

Ciao
Hannes & Kepeng

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 12 Jun 2017 21:03:42 +0000

So I believe that there are other uses for this technology, for instance here at Microsoft we have "compact tokens" and looking forward to using CWT and POP as a standard instead of what we have created. FIDO also has a use case for CWT and POP for the Client to Authenticator Protocol, which uses CBOR and CWT today. I think it makes sense to define POP for CWT in it's own specification as there will be many stand-alone usages for POP for CWT.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, June 12, 2017 11:19 AM
To: [email-masked]
Cc: Hannes Tschofenig <[email-masked]>; Kepeng Li <[email-masked]>
Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs)

Hi all,

RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec.

The ACE working group is planning to also define a CBOR/COSE equivalent of RFC 7800 and is interested in knowing how you might use CBOR proof-of-possession keys for CWTs.

Please drop us a message if you are using CBOR PoP keys for CWTs. We would like to learn more about your usage.

Ciao
Hannes & Kepeng

_______________________________________________
Ace mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=02%7C01%7Ctonynad%40microsoft.com%7C0f499d2726c74f8c11ab08d4b1bf922f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636328883729061751&sdata=hxYGYRTqzC1qIEo4efvJdc%2B99GRldim68GwELwGIc8M%3D&reserved=0

---

From: Mike Jones <[email-masked]>
Date: Mon, 12 Jun 2017 21:11:27 +0000

I'll add to this that if the FIDO 2.0 Client to Authenticator Protocol (CTAP) spec uses this PoP key representation, one of the callers of this will be implementations of the W3C WebAuthn specification.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, June 12, 2017 11:19 AM
To: [email-masked]
Cc: Hannes Tschofenig <[email-masked]>; Kepeng Li <[email-masked]>
Subject: [Ace] Potential uses of PoP keys in CBOR Web Tokens (CWTs)

Hi all,

Ciao
Hannes & Kepeng

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Renzo Navas <[email-masked]>
Date: Mon, 19 Jun 2017 15:11:05 +0200

Hello Hannes, Kepeng, ACE

I used the PoP key concept, to map on top of it other Authenticated
Key Establishment (AKE) exchanges (aside from the default one on OAuth
that uses timestamps). This generic use I presented on IETF 95 [1].

More relevant to the current question on ACE, I put this idea more
close to reality, I co-authored a paper which we do the actual mapping
of one AKE protocol to the ACE-OAuth architecture using CWT,
"Nonce-based authenticated key establishment over OAuth 2.0 IoT
proof-of-possession architecture" [2]. On this google doc [3] there is
more detail about the actual messages that should be sent.

This was more than one year ago. So it differs with the current state
of the are of ACE WG, and CWT.

The high level solution goes as this:
the CWT have to be linked to the current run of the AKE protocol. In
order to achieve so I chose to extend the COSE_Key object to be able
to transport relevant authenticated key establishment information
(nonces and entities-id's). So the final CWT  will contain (on the
"ck") a COSE_Key that will allow the RS to validate the full AKE
exchange: hence the CWT is fresh and we have also the key that goes
with it.

Today I'm not sure if I'll do it the same way (extend the COSE_Key
object) , but rather I think a more generic CBOR object can be defined
with appropriate security services to transport different information
needed by the AKE protocol exchange, that in the end will be also
liked to the CWT.

Some time ago, we had some talks with Ludwig and Göran to try to put
this into practice-IETF, but was indeed a little bit haunting to
define a generic framework to run on top of it any AKE protocol linked
to a PoP-key/CWT.
(So, that's why we went first for a  time synchronization solution, to
at least enable the current IETF PoP exchange to work)

I don't know if there is real need for nonce-based PoP Keys/CWT
solutions on industry.

My 2 cents,

Renzo

[1] https://www.ietf.org/proceedings/95/slides/slides-95-ace-3.pdf
[2] https://hal.archives-ouvertes.fr/hal-01522039v1
[3] https://docs.google.com/document/d/1xzc3hUJhCEtT6_HoW2gLoBiXfNk-ID57gUs6XftlIIc/edit?usp=sharing

---

From: John Bradley <[email-masked]>
Date: Wed, 21 Jun 2017 15:01:15 -0500

I don’t have any deployments yet, but am changing companies in July and can see some future use cases for POP CWT around Web Authentication.

POP for JWT is taking off and Ping has implementations of that.

It would be beneficial if we could maintain the same confirmation “cnf” semantic between JWT and CWT.

I suspect that there are going to be gateways and mixed environments, so it will reduce confusion.

If you are asking about specific confirmation methods you need to give me a bit of time to swap some of this into my head.
The high level semantic of a confirmation element should be the same but even in JWT there are different methods and information that needs to be propagated depending on the application eg key hash vs DN vs encrypted symmetric key.

John B.

> On Jun 12, 2017, at 1:19 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>