Re: [OAUTH-WG] OSCORE

[Hannes Tschofenig <[e-mail]>]

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: Dave Thaler [mailto:[e-mail]]
Sent: 07 February 2018 17:27
To: Göran Selander; Hannes Tschofenig; [e-mail]
Cc: [e-mail]
Subject: RE: [OAUTH-WG] OSCORE

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:[e-mail]]
Sent: Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig <[e-mail]>; [e-mail]; Dave Thaler <[e-mail]>
Cc: [e-mail]
Subject: Re: [OAUTH-WG] OSCORE

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" <[e-mail]> 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
>
>
>-----Original Message-----
>From: Göran Selander [mailto:[e-mail]]
>Sent: 07 February 2018 15:37
>To: Hannes Tschofenig; [e-mail]
>Cc: [e-mail]
>Subject: [OAUTH-WG] OSCORE
>
>
>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://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
>
>
>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://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
>>
>> (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.
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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
>>
>
>
>
>
>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.

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.