Subject: [OAUTH-WG] OSCORE

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 10:06:41 +0000

Hi guys,

You may be interested to hear that a group of people working on Internet of Things security believe they have found a solution to deal with the challenges we had in protecting HTTP requests/responses.

Here is the draft: https://tools.ietf.org/html/draft-ietf-core-object-security-07
(The draft is mostly focused on CoAP but it is supposed to be applicable also to HTTP.)

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Göran Selander <[email-masked]>
Date: Wed, 7 Feb 2018 15:37:03 +0000

Hi Hannes, and all

Thanks for the announcement.

To be a little bit more precise, the statement is that a CoAP-mappable
HTTP message can be mapped to CoAP (using RFC 8075), protected with OSCORE
(as specified in the referenced draft) and transported with HTTP (as
exemplified in the referenced draft). The main use case is in conjunction
with an HTTP-CoAP translational proxy (RFC 8075), and the mapping would
with this construction result in a CoAP-mappable HTTP request being
protected by an HTTP client and verified by a CoAP server.

This functionality was proposed by OCF for their end-to-end REST use
cases. Happy to hear any comments on the construction as described in the
draft.

Note that Hannes referenced the wrong version of the draft, here is the
latest:
 
https://tools.ietf.org/html/draft-ietf-core-object-security-08

Göran

On 2018-02-07 11:06, Hannes Tschofenig wrote:
> Hi guys,
>
> You may be interested to hear that a group of people working on Internet
> of Things security believe they have found a solution to deal with the
> challenges we had in protecting HTTP requests/responses.
>
> Here is the draft:
> https://tools.ietf.org/html/draft-ietf-core-object-security-07
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium. Thank you.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 15:47:47 +0000

Hi Göran,

Maybe you can then answer the question whether this is useful / applicable to a HTTP. Asked differently, under what conditions does the OSCORE not work for HTTP. This would help the folks in the group, including me, to determine whether this actually something we should be looking into at all. Note that typical applications that use OAuth do not use CoAP -- only HTTP.

In OAuth we had for several years tried to get HTTP message protection working and we have, unfortunately, failed to find a suitable solution.

Ciao
Hannes

-----Original Message-----
From: Göran Selander [mailto:[email-masked]]
Sent: 07 February 2018 15:37
To: Hannes Tschofenig; [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] OSCORE

Hi Hannes, and all

To be a little bit more precise, the statement is that a CoAP-mappable HTTP message can be mapped to CoAP (using RFC 8075), protected with OSCORE (as specified in the referenced draft) and transported with HTTP (as exemplified in the referenced draft). The main use case is in conjunction with an HTTP-CoAP translational proxy (RFC 8075), and the mapping would with this construction result in a CoAP-mappable HTTP request being protected by an HTTP client and verified by a CoAP server.

This functionality was proposed by OCF for their end-to-end REST use cases. Happy to hear any comments on the construction as described in the draft.

Göran

On 2018-02-07 11:06, Hannes Tschofenig wrote:
> Hi guys,
>
> You may be interested to hear that a group of people working on
> Internet of Things security believe they have found a solution to deal
> with the challenges we had in protecting HTTP requests/responses.
>
> Here is the draft:
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
>

---

From: Göran Selander <[email-masked]>
Date: Wed, 7 Feb 2018 16:00:00 +0000

Hi Hannes,

Including Dave who may want to provide some background to the use case.

As I said, this was a proposed construction and was straightforward to
include in the draft. I’m not the right person to answer whether this is
useful for OAuth, but I’m interested in the answer.

Göran

On 2018-02-07 15:47, "Hannes Tschofenig" <[email-masked]> wrote:

>Hi Göran,
>
>Maybe you can then answer the question whether this is useful /
>applicable to a HTTP. Asked differently, under what conditions does the
>OSCORE not work for HTTP. This would help the folks in the group,
>including me, to determine whether this actually something we should be
>looking into at all. Note that typical applications that use OAuth do not
>use CoAP -- only HTTP.
>
>In OAuth we had for several years tried to get HTTP message protection
>working and we have, unfortunately, failed to find a suitable solution.
>
>Ciao
>Hannes
>
>
>HTTP message can be mapped to CoAP (using RFC 8075), protected with
>OSCORE (as specified in the referenced draft) and transported with HTTP
>(as exemplified in the referenced draft). The main use case is in
>conjunction with an HTTP-CoAP translational proxy (RFC 8075), and the
>mapping would with this construction result in a CoAP-mappable HTTP
>request being protected by an HTTP client and verified by a CoAP server.
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Feb 2018 17:26:41 +0000

As Göran said, yes the original rationale was end-to-end communication through proxies where each leg might be CoAP or might be HTTP,
the most common case being a single COAP-to-HTTP or HTTP-to-COAP proxy.   For the subset of HTTP that is mappable to CoAP
(i.e., simple RESTful calls), I'm not aware of any reason it wouldn't work with a simple HTTP proxy where all legs are HTTP.
It would be good if someone could try that and verify it though... maybe a hackathon project.

-----Original Message-----
From: Göran Selander [mailto:[email-masked]] 
Sent: Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]; Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OSCORE

Hi Hannes,

As I said, this was a proposed construction and was straightforward to include in the draft. I’m not the right person to answer whether this is useful for OAuth, but I’m interested in the answer.

Göran

On 2018-02-07 15:47, "Hannes Tschofenig" <[email-masked]> wrote:

>looking into at all. Note that typical applications that use OAuth do 
>not use CoAP -- only HTTP.
>
>cases. Happy to hear any comments on the construction as described in 
>the draft.
>
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.
>ietf.org%2Fhtml%2Fdraft-ietf-core-object-security-08&data=04%7C01%7Cdth
>aler%40microsoft.com%7C0c70175ce7634698e06a08d56e43f36c%7Cee3303d7fb734
>b0c8589bcd847f1c277%7C1%7C0%7C636536160483223433%7CUnknown%7CTWFpbGZsb3
>d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sda
>ta=Qgb2gvkV5uBIj36ogAYluaN08PS9YuyXz%2FlJzls1U9g%3D&reserved=0
>
>
>Göran
>
>
>> Internet of Things security believe they have found a solution to 
>> deal with the challenges we had in protecting HTTP requests/responses.
>>
>> Here is the draft:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
>> s.ietf.org%2Fhtml%2Fdraft-ietf-core-object-security-07&data=04%7C01%7
>> Cdthaler%40microsoft.com%7C0c70175ce7634698e06a08d56e43f36c%7Cee3303d
>> 7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536160483223433%7CUnknown%7CTW
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3
>> D%7C-1&sdata=k4MlHEBM0YayRoq%2B0KjIBdzShfXMSW2EQDK03%2FMCJ%2B0%3D&res
>> erved=0
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cdthaler%40micros
>> oft.com%7C0c70175ce7634698e06a08d56e43f36c%7Cee3303d7fb734b0c8589bcd8
>> 47f1c277%7C1%7C0%7C636536160483223433%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=KYCV
>> h3AxIuXfGoA0R4W6poXbhN%2B1jKDAkQgNygIYhmM%3D&reserved=0
>>
>
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 7 Feb 2018 17:33:49 +0000

Is there any implementation / prototyping experience with this work, Dave?

Here is what we have been working on in the context of OAuth: With OAuth 1.0: https://tools.ietf.org/html/rfc5849 one of the problems there was the fields we computed the digest over were changed by proxies, and other middleware. Needless to say that the verification failed and for developer it was not clear which field caused the digest verification to fail.

In https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 we followed a different design approach where we apply the digest selectively over field and they are repeated in the newly defined parameter.

Ciao
Hannes

-----Original Message-----
From: Göran Selander [mailto:[email-masked]]
Sent: Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]; Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OSCORE

Hi Hannes,

Göran

---

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Feb 2018 17:46:27 +0000

Oscore was designed by looking at the specs for HTTP/COAP proxying, so that it should work with any such proxy that's compliant to the spec.
I'm not aware if there's implementation experience yet, but the key concept is that fields that have to be preserved end-to-end are tunneled through the proxy, rather than left where the proxy can modify them.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, February 7, 2018 9:34 AM
To: Dave Thaler <[email-masked]>; Göran Selander <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OSCORE

Here is what we have been working on in the context of OAuth: With OAuth 1.0: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5849&data=04%7C01%7Cdthaler%40microsoft.com%7C1fc9d72fd1cc4d9d15d308d56e50f450%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536216338303660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=P0DowVhk17vbb7EZK6CmUcIOLjnfu8%2FDEu6q9QDS%2FGI%3D&reserved=0 one of the problems there was the fields we computed the digest over were changed by proxies, and other middleware. Needless to say that the verification failed and for developer it was not clear which field caused the digest verification to fail.

In https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-signed-http-request-01&data=04%7C01%7Cdthaler%40microsoft.com%7C1fc9d72fd1cc4d9d15d308d56e50f450%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536216338303660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=LFitneeXJMHlGa26jzpuHH673WYFlCBTol5B9z7v18g%3D&reserved=0 we followed a different design approach where we apply the digest selectively over field and they are repeated in the newly defined parameter.

Ciao
Hannes

-----Original Message-----
From: Göran Selander [mailto:[email-masked]]
Sent: Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]; Dave Thaler <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OSCORE

Hi Hannes,

Göran